ci: remove edited type trigger from enforce-release-source

[trueberryless]

🧭 Context

CI on main is (seemingly randomly) failing because the enforce-release-source action 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:

1. the commit from main lands in the automatically generated next release PR, which causes the enforce-release-source action to trigger because of the synchronize type
2. the release-pr workflow updates the PR description, which causes the enforce-release-source action to trigger a second time within a short time frame because of the edited type

This results in two workflow runs getting triggered and one getting cancelled because both events trigger quickly after each other. Therefore, removing the edited type 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 the edited type would be my solution. I also explicitly set cancel-in-progress to false to 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.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ready	Preview, Comment	Jul 5, 2026 6:10pm
npmx.dev	Ready	Preview, Comment	Jul 5, 2026 6:10pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
npmx-lunaria	Ignored		Jul 5, 2026 6:10pm

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR updates the enforce-release-source GitHub Actions workflow to trigger on PR commit synchronizations (synchronize) instead of PR edits, and it adds cancel-in-progress: false to the workflow concurrency configuration.

Changes

Workflow configuration updates

Layer / File(s)	Summary
Trigger event types .github/workflows/enforce-release-source.yml	Replaced pull_request_target.types entry edited with synchronize so the workflow runs on commits pushed to a PR.
Concurrency configuration .github/workflows/enforce-release-source.yml	Added cancel-in-progress: false beneath the existing concurrency.group setting to prevent automatic cancellation of in-progress runs.

Suggested reviewers

• MatteoGabriele

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description check	✅ Passed	The pull request description clearly explains the context, identifies the root cause of CI failures, and details the specific changes being made to resolve the issue.
Title check	✅ Passed	The title accurately describes a key workflow change: removing the edited trigger from enforce-release-source.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[trueberryless]

Well, that was unexpected: https://github.com/npmx-dev/npmx.dev/actions/runs/27443844535/job/81124080867#step:3:1

🤣

[ghostdevv]

How confident are you with this? @trueberryless

[trueberryless]

How confident are you with this? @trueberryless

70% because it has been some time since I investigated this. Back then probably 90% 😅

[ghostdevv]

How confident are you with this? @trueberryless

70% because it has been some time since I investigated this. Back the probably 90% 😅

Do you think we should still merge this? Or should we give it some more time to figure it out?

[trueberryless]

Do you think we should still merge this? Or should we give it some more time to figure it out?

I'll revisit my ideas and will let you know 👍

[alexdln]

Looks like now we can let it check and then change the branch right before merging (and without the "edited" trigger, this check will not restart)...

[ghostdevv]

Looks like now we can let it check and then change the branch right before merging (and without the "edited" trigger, this check will not restart)...

wdym?

[alexdln]

The edited trigger allows the workflow to restart whenever a change occurs - whether to the name, description, or base branch.
If we remove it - the workflow may not restart automatically after the base branch changes (and remain in the "passed" state, making this check bypassable)

[trueberryless]

The edited trigger allows the workflow to restart whenever a change occurs - whether to the name, description, or base branch. If we remove it - the workflow may not restart automatically after the base branch changes (and remain in the "passed" state, making this check bypassable)

Okay, but do we need the synchronise type then? Because a new commit can't change the base branch 🤔