Context

In a PR there was an odd failure of the pkgs/by-name check: After a base branch change, it seemingly complained about new non-pkgs/by-name packages introduced by the PR (see #275539 that introduced this new check). Even though the PR only had a single unrelated commit on top of staging at that point.

Why did this happen? Here's the series of events leading to that:

• PR opened with master as the base branch
  This triggered CI, completing successfully

• Marked as draft, presumably to avoid the many review requests when changing the base branch in the next step

• Force pushed, presumably to staging + the changes
  At this point, master is still the base branch, and if the PR were merged at that point, master would've gotten all commits from staging.
  Since the pkgs/by-name checker compares the PR against the base branch of it, it correctly failed with the packages that would've been new on master and aren't using pkgs/by-name yet!

  Also this can only cause failures right now because the two new relevant packages in staging were merged before pkgs/by-name started being enforced (Vulkan 1.3.275 #281591 and libplacebo: 5.264.1 -> 6.338.1 #269415). Now that pkgs/by-name is being enforced (notably for all base branches), it's going to get very improbable.

• Only afterwards, the base branch was changed to staging.
  However, the pull_request_target GitHub Actions event doesn't trigger for base branch changes by default!

One way to "fix" that is to instead push the merge base of the old and new base branch before switching. This way you also won't have to mark it as a draft to avoid requesting reviews by everybody.

But the better fix is to make CI retrigger when the base branch changes!

This work is sponsored by Tweag and Antithesis ✨

Changes

This PR changes the pkgs/by-name check workflow to also trigger when the base branch changes. This type of event doesn't trigger CI by default:

By default, a workflow only runs when a pull_request_target event's activity type is opened, synchronize, or reopened.

Instead it's part of the edited event, which however also triggers in other cases:

The title or body of a pull request was edited, or the base branch of a pull request was changed.

However, this workflow is fairly quick, and PR's don't get edited that often, so it shouldn't be a problem.

Ping @zeuner

Things done

• Tested that it works:
  • Base branch trigger test tweag/nixpkgs#83

Add a 👍 reaction to pull requests you find important.