web-features bot improvements for interop 2027 - #1318
Conversation
| process-issue: | ||
| if: github.event_name == 'issues' | ||
| runs-on: ubuntu-latest | ||
| concurrency: |
There was a problem hiding this comment.
How many jobs might this trigger if we close issues en masse or add a lot of labels? GitHub Actions should just queue everything to eventually run, but if we know it'll be hundreds of jobs at the same time, that seems like it might break?
There was a problem hiding this comment.
This is really here to avoid the case where the same issue is updated multiple times while a job for that issue is already running. With this concurrency block, the next jobs will be queued instead of running in parallel.
If I'm editing the opening comment of an issue twice in less time than it takes the job to run, then I don't run the 2 jobs at the same time, potentially ending up with the wrong content if the second ran faster than the first.
That said, I'm realizing that cancel-in-progress:true would make more sense. We only care about the final state of the issue, not the in-between edits. So a later job on an issue should be allowed to cancel an earlier job. I'll change this.
As for a batch editing of hundreds of issues, I'm not seeing an issue here. We'll let GitHub queue up all the jobs.
jgraham
left a comment
jgraham
left a comment
There was a problem hiding this comment.
Basically OK, although I'm quite confused with the comment creation flow.
In the future it would be really useful to separate out the changes into more commits; reviewing a mixture of minor formatting changes and multiple different feature changes is much harder.
| "devDependencies": { | ||
| "octokit": "^5.0.3", | ||
| "web-features": "^2.48.0", | ||
| "web-features": "^3.34.2", |
There was a problem hiding this comment.
Should we also configure dependabot to automatically update this?
There was a problem hiding this comment.
Yes we should. Not sure exactly how this works, but I can look into it next.
… the feature catalog
Apologies for the messy initial changes. I've addressed review comments in a series of logical commits now. |
| # The process-issue job runs when a single issue is opened, edited, reopened or labeled. | ||
| process-issue: | ||
| if: >- | ||
| github.event_name == 'issues' && |
There was a problem hiding this comment.
This is fine, but one could also use a condition like contains(github.event.issue.labels.*.name, 'focus-area-proposal') to only select focus area proposal issues irrespective of the trigger.
3 participants
Fixes #1317.
Sorry that's a large PR with a lot of code changes. Hopefully, the summary above is helpful.
For what it's worth, the same code also lives at https://github.com/captainbrosset/interop-proposals-bot and I tested it by opening a few issues on that repo. If you want to test the new action/script more, feel free to open and edit issues on my personal repo.