fix: remove edited type trigger from enforce-release-source ci#2896
fix: remove edited type trigger from enforce-release-source ci#2896trueberryless wants to merge 2 commits into
edited type trigger from enforce-release-source ci#2896Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
📝 WalkthroughWalkthroughThis PR updates the enforce-release-source GitHub Actions workflow to trigger on PR commit synchronizations ( ChangesWorkflow configuration updates
Suggested reviewers
Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error)
✅ Passed checks (3 passed)
✨ 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
Well, that was unexpected: https://github.com/npmx-dev/npmx.dev/actions/runs/27443844535/job/81124080867#step:3:1 🤣 |
enforce-release-source ciedited type trigger from enforce-release-source ci
🧭 Context
CI on main is (seemingly randomly) failing because the
enforce-release-sourceaction gets cancelled. This PR aims to fix this issue.📚 Description
To my understanding, the problem is cause because merge queues quickly add commits to main, which causes two things:
enforce-release-sourceaction to trigger because of thesynchronizetyperelease-prworkflow updates the PR description, which causes theenforce-release-sourceaction to trigger a second time within a short time frame because of theeditedtypeThis results in two workflow runs getting triggered and one getting cancelled because both events trigger quickly after each other. Therefore, removing the
editedtype should resolve the issue, as it removes one of the concurrent runs. Since an edit of the PR description does not include target branch changes, removing theeditedtype would be my solution. I also explicitly setcancel-in-progresstofalseto avoid future confusion.So I think this cancellation happens seemingly random because workflows just do not take the same time always, resulting in the cancellation sometimes happening because of timing reasons, and sometimes not.
This is just how I understood it after debugging for the last 2 hours. I would really appreciate another four eyes on my deduction.