Run Release Drafter action as last step of CI#264
Conversation
WalkthroughConsolidates Release Drafter logic by removing the standalone Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.github/workflows/app-ci.yaml:
- Around line 228-238: The update_release_draft job currently runs Release
Drafter but lacks the job-level permission to create releases; add a job-level
permissions block under the update_release_draft job with contents: write so the
release-drafter/release-drafter step can create draft releases, and also update
the caller workflow (addon-ci.yaml) to grant contents: write at workflow or job
level so the intersected permissions allow write access; target the
update_release_draft job and the caller workflow's permissions settings when
making the change.
In @.github/workflows/workflows-ci.yaml:
- Around line 74-87: The update_release_draft job currently runs with
workflow-level permissions set to contents: read, causing Release Drafter to
fail; update the job definition for update_release_draft to include a job-level
permissions block that grants contents: write (so the
release-drafter/release-drafter action can create/update draft releases), e.g.
add a permissions: section under the update_release_draft job and set contents:
write to override the workflow-level read-only setting for that job.
frenck
left a comment
There was a problem hiding this comment.
Meh ran into it a few times. I lack a better solution. Let's go with this one 👍
Thanks, @lmagyar!
../Frenck
Blogging my personal ramblings at frenck.dev
|
Wait, wait! We should:
|
Pinning solves that, every change is causing a PR against the other repos (that migrated to the new workflow, the others are on hold until that happened).
Good point, we can do that, and just ship another release 👍 ../Frenck
Blogging my personal ramblings at frenck.dev |
addons-ci.yaml: So nothing to do. :) |
|
Even better :) |
|
Still something is strange. The workflows-ci.yaml, modified in this PR, runs fine during CI, runs the rel. drafter, but without a proper .github/release-drafter.yml file checked into this repo??? In my fork it fails, because there is no .github/release-drafter.yml, it's true, but there is no file in this upstream repo either, and it runs here, what's going on??? |
Having a dedicated repo called .github is the same as having a folder .github in your repository. From the release-drafter readme:
|
In hassio-addons/workflows#264 it was moved to the end of app-ci.yaml.
|
@einschmidt Wow, thank you, I had no clue about this. |
Proposed Changes
Github tends to trigger the workflow run before their database behind their GraphQL API finishes processing the event that triggered the workflow run. And rel. drafter uses the GraphQL API. Eg. I had to re-run this WF run manually to get the triggering PR into the drafted release: https://github.com/hassio-addons/app-tailscale/actions/runs/21766534501
If the last PR is a breaking change, this can have serious consequencies.
We can add an eg. 15s delay to the rel.drafter workflow or move it to the end of the CI workflow, I suggest the later.
Maybe this should be done in 3 steps:
Related Issues
release-drafter/release-drafter#871
Summary by CodeRabbit