Skip to content

fix(ci): stop submission workflows running twice on a new issue - #126

Merged
perminder-klair merged 1 commit into
mainfrom
fix/duplicate-submission-comments
Oct 30, 2026
Merged

perminder-klair merged 1 commit into
mainfrom
fix/duplicate-submission-comments

Conversation

@perminder-klair

Copy link
Copy Markdown
Contributor

Summary

Every new submission ran its workflow twice, because the issue form applies its label at creation and both opened and labeled fired. #105 stopped the duplicate success comment, but failures still posted twice. #123 shows it: two identical comments, 6 seconds apart.

 on:
   issues:
-    types: [opened, edited, labeled]
+    types: [edited, labeled]

-    if: contains(join(github.event.issue.labels.*.name, ','), 'persona-submission')
+    if: contains(join(github.event.issue.labels.*.name, ','), 'persona-submission') && (github.event.action != 'labeled' || github.event.label.name == 'persona-submission')

Applied to all five submission workflows.

  • opened is removed. A run needs the submission label, and a label present at creation always comes with a labeled event, so opened only added a second run. This also fixes the catalog check failure comment, which doubled the same way.
  • The job ignores other labels. A maintainer adding something like bug to a failed submission would otherwise re-run it and repeat the failure.
  • Retries still report. A contributor's edit that still fails posts a new comment, and so does re-applying the submission label, because each one shows the retry happened and gives the current error.

Evidence

Each workflow's real build-pr script ran against a mock GitHub with a failing submission, using the event sequence a new issue fires:

Scenario Before After
New failing submission 2 identical comments 1 comment
Maintainer adds another label runs no run
Contributor edits the issue runs runs
Submission label re-applied runs runs

All five workflows gave the same results. Issue timelines for #123 and #114 show the label's labeled event firing at creation for contributors without repo access, and #114's creation shows the same pair of runs.

issues events only run from main, so the trigger change can't be exercised live from this branch. The closest real run is the labeled-only rebuild of #123, which opened #125 and passed validation. The first submission after merge will confirm it.

The issue templates apply their label at creation, so `opened` and `labeled`
both fired and every new submission ran twice. f525f54 gated the success
comment, but the failure comment and the catalog check report still posted
twice (#123).

Drop `opened`, since a submission's label always arrives with a `labeled`
event, and ignore any label other than the workflow's own so a maintainer
labelling a failed submission doesn't repeat the failure.
@perminder-klair
perminder-klair merged commit 7df4a51 into main Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant