We tried, but GitHub's markdown renderer will render these newlines
there, so going back to "real" paragraphs.
Also fixed the emphasis slightly, since "via Issues" is not bold, "via a
Pull Request" is also made not bold for consistency. Puts the focus more
on the "contribute" link as well.
(cherry picked from commit 57cf218357)
This isn't an issue template; it's a stub that will be auto-closed by CI
and is meant to discourage future package requests, and encourage more
pull requests.
See the full discussion on https://github.com/NixOS/nixpkgs/issues/425040.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
(cherry picked from commit f2bb8a4dfb)
This only happens when the label workflow runs in pull_request context
*and* from within nixpkgs (not a fork). This is the case for dependabot
updates.
(cherry picked from commit 979687958f)
When a user deletes their account, they appear as a "ghost user". This
user is represented as `null` on API requests. If such a user had posted
a review before, this breaks a few places, which assume to be able to
access `user.login`.
(cherry picked from commit 41ae23c0e7)
When a contributor mistakenly sets the wrong target branch for a Pull
Request, this can lead to bad consequences for CI. Most prominent is the
mass ping of codeowners, that is already handled in
`ci/request-reviews/verify-base-branch.sh`. But there are other things
that go wrong:
- After eval, a mass ping of maintainers would still be possible, in
theory. Practically, this doesn't happen, because we have a limit of 10
reviewer requests at the same time.
- This will most often contain a change to `ci/pinned.json`, thus the
full Eval matrix of all Lix/Nix versions will be run, burning a lot of
resources.
- The PR will be labelled with almost all labels that are available.
We can improve on the current situation with some API calls to determine
the "best" merge-base for the current PR. We then consider this as the
"real base". If the current target is not the real base, we fail the
prepare step, which is early enough to prevent all other CI from
running.
(cherry picked from commit 87d9b08ffb)
This moves the no-channel-base check into the prepare script to exit
early and prevent all of CI to run against those branches. We also
provide better output by posting a "Changes Requested" review, using the
existing infrastructure from the old cherry-picks check.
The review will be dismissed automatically once the branch has been
corrected, because the commits check will run and do it.
(cherry picked from commit 0601cf6fd0)
This is the very first step to extending the commits job to do more than
just cherry-picks in the future: It could check reverts or merge
commits, but also the commit message format and more.
Of course, cherry-picks are still just checked on the stable branches as
before. For now, this allows us to run the part that dismisses automated
reviews automatically. This helps us when we do branch related checks in
the prepare step, which would also create such a review. To avoid
cluttering multiple reviews across a PR, we'll want all of these reviews
to be handled by the same code, thus this change.
(cherry picked from commit b6bbf7b250)
The owners check is not reproducible, because it depends on the state of
the NixOS org on GitHub. Owners can rename their accounts or they can
leave the organisation and access to Nixpkgs can be removed from teams.
All of this breaks the owners check for reasons unrelated to the PR at
hand.
This PR makes the check for the owners file conditionally required: Only
when the ci/OWNERS file is actually modified a failed check will block
merging the PR. When that's not the case, the check will still fail
visibily in the checklist, but the failure can be ignored.
This is especially relevant for the Merge Queue, which should not be
entirely blocked whenever any of these events happen.
Also, it allows passing the checks in a fork when testing, where the
owners check will *always* fail, because the respective teams and
members are never part of the "user org" that a fork is.
(cherry picked from commit 956d0a744d)
The required status checks should depend on exactly one workflow,
triggered via pull_request_target or merge_group. Anything that is
triggered by pull_request is for testing purposes of the workflows
themselves only.
(cherry picked from commit 5ff32763b2)
Posting the status manually allows us to avoid the strange "skipped ==
success" logic and properly skip the `unlock` job for pull_request
events in the next commit.
This should be much easier to understand than the previous logic.
(cherry picked from commit 2c25cb0891)
Changes to the merge-group workflow should also validate that the file
is hooked up correctly and works - otherwise we risk merging CI changes
that cause the merge queue to fail consistently.
(cherry picked from commit 534d41ee9c)
Previously, the test for the push workflow was running on the HEAD
commit of the PR only. It would be better to run it on the merged result
instead, just like any other tests we run in a PR.
(cherry picked from commit 06a0eba240)
This workflow runs the PR and Push workflow files on a `pull_request`
trigger. The intent is to test changes to the workflow files
immediately. Previously, these were run directly from the respective
workflow files.
The new approach allows us to move the logic to run this only when
workflow files changed from the pull_request trigger into a job. This
has the advantage that older jobs are cleaned up, when the PR changes
from a state of "workflow files changed" to "no workflow files changed".
This can happen when changing a PR's base from staging to master, in
which case changes from master would temporarily appear in the PR as
changes. When these include changes to workflow files, this would
trigger the PR workflow via `pull_request`. Once the base is changed,
the PR is closed and re-opened, so CI runs again - but since it's on the
same commit and the new run doesn't trigger `pull_request`, the results
of the previous run are still kept and displayed. These results may
include cancelled or failed jobs, which are impossible to recover from
without another force-push.
Checking this condition at run-time is only possible, because we move it
into a separate workflow, turning the `pr.yml` workflow into a re-usable
workflow. This will make sure to skip the whole workflow at once, when
no change was detected, which will prevent the "no PR failures" job from
appearing as skipped - which would imply "success" and make the PR
mergeable immediately. Instead the "no PR failures" job is not shown at
all for this trigger, which is generally what we want.
Do the same for `push.yml` for consistency.
(cherry picked from commit 443f30f811)
Both `nix flake check` and `nix-env` are single-threaded, so no reason
to serialize their calls and waste time.
This brings down the runtime for this job from ~1:51 to ~1:27 in my
tests.
(cherry picked from commit 3d9cb9f355)
In fb32eb0f29 we moved the checked-out
worktrees into a `nixpkgs` directory. Update the input descriptions to
reflect this.
(cherry picked from commit c25dd6c655)
The python-updates branch is not a "development" branch in the sense of
ci/README.md's classification. That's because it allows force pushes.
When rewrites are possible, cherry-picking from this branch should not
be allowed, because the commit references will potentially end up out of
sync.
These kind of branches are now termed "Work-in-Progress" branches. Up
until recently these branches didn't work well for Pull Requests
targeting them, because Eval wouldn't run on them with a push event and
thus, Eval in the PR couldn't succeed either. That's now fixed, PRs
towards *any* WIP branch should work correctly.
(cherry picked from commit 55b046451c)
Instead of uploading the outpaths as artifact, this uploads them via
cachix. Most of all, this makes CI less brittle, because Eval in PRs
will still be able to succeed, even if no workflow run for the push
event could be found on the target branch. It will just take longer.
This also makes moving Eval into the Merge Queue easier to do: When
downloading artifacts from a different run, these would always have to
match on the right event, too. By pulling from cachix, the same workflow
can support target branches with merge queue and without merge queue at
the same time. The latter would still use the push event, while the
former could use the merge_group event.
Last but not least, this should fix Eval on PRs targeting `wip-`
branches and any other branches that the push event doesn't trigger on.
These would never find an Eval result from the target branch and could
never show rebuilds accurately. Now these PRs should work at a slightly
higher runtime cost.
(cherry picked from commit c1b06db57b)
With the latest performance improvements, this only adds up to 1s, but
reduces complexity in managing pinned checkouts explicitly, especially
when we need *both* pinned checkouts in the next commit.
(cherry picked from commit c18d1e4af8)
This fixes problems on darwin, where the new tmpfs folder would not be
fully empty, but git only creates worktrees on fully empty directories.
(cherry picked from commit fb32eb0f29)
Instead of fetching up to 3 times on each new checkout, we now fetch all
the commits we're going to need at once. Afterwards, we checkout the
different worktrees in parallel, which doesn't give us much, yet,
because it would still be IO-bound on its own. Inconsistent IO
performance on disk is also the biggest limitation for checkout right
now, where checkout times range everywhere from 20s to 40s.
By checking out the worktrees on a tmpfs, the actual checkout only takes
1s and benefits from parallelization. The overall checkout time is now
8-11s, depending on the number of commits.
That's a reduction of 10-30s and we get this speedup for almost every
job in the PR workflow, which is huge.
This potentially has a nice side-effect for Eval, too: Because the repo
is in RAM, Eval seems to run slightly faster, up to 10 seconds less.
(cherry picked from commit 4b4aa628da)
The two as-at inputs, were not boolean anymore, but GHA didn't complain.
Input types are actually not a thing for composite actions - they are
only documented for callable workflows.
(cherry picked from commit f01b6b4754)
This is the default, but who's supposed to know about that? Let's make
it explicit to be clear about the availability of files in `ci/`.
(cherry picked from commit f35d1cd2cc)
This moves the logic to "check whether the PR can be merged and
determine the relevant commits" into the PR / prepare job directly -
since that's the only place where it is supposed to be used.
Because of the if condition in get-merge-commit, this logic was run
multiple times, for example in the lint workflow, where only one of
targetSha or mergedSha was provided as input. However, this input was
thrown away directly. This might not be a big problem, because this was
not expensive, so far. But with the next commit, this will become more
so.
This also separates the logic a bit cleaner - `prepare` figures out all
the parameters for the whole PR workflow, while `checkout` handles the
consistency around these checkouts.
(cherry picked from commit b51e104439)
By definition the tarball changes on every commit, so it makes no sense
to cache it - it will just waste disk space.
(cherry picked from commit ac93865697)
For PRs targeting a fast moving branch like master, it might not
actually help because the merge commit will still be different on each
run. But on slower moving branches or when testing in a fork, it can
speed things up.
Since each of these build results is only a few hundred bytes without
any dependencies, it has essentially no cost.
Not adding this to `treefmt`, because this looks at *all* the files in
the repo, so needs to re-run even when iterating on CI only.
(cherry picked from commit 6ee40e7931)
Pushing the source path to cachix is pointless, because the only source
we're using is Nixpkgs - and that will always be available already via
checkout. No need to ever substitute it, so no need to push it either.
(cherry picked from commit 2400bdf0d4)
This allows setting up a custom cachix cache in a contributor's fork.
That's most valuable when working on CI itself, testing and interating
in a fork. It's required when working on cachix related features
directly.
(cherry picked from commit 025424913f)
These two jobs mostly used the same code anyway, so they can easily run
in the same job. This uses fewer resources and avoids running (and
failing) the codeowners review job on Pull Requests from development
branches like staging-next or haskell-updates.
It also opens the door for more improvements later on, for example it
will be much easier to implement a shared reviewer limit for both owners
and maintainers now.
(cherry picked from commit ddf81dead6)
Changes to this file already trigger a run of this workflow via the PR
workflow, we don't need to run this *another* time.
(cherry picked from commit 7f4dd7e2ff)
This runs the "check owners" job as part of the main PR workflow, with
multiple advantages:
- The job doesn't run anymore when undrafting a PR, where it's not
required, because the OWNERS file's contents didn't change.
- A valid OWNERS file is now a requirement to merge a PR.
- The OWNERS file is always checked on the exact same test merge commit
that the remainder of the workflows are running on as well.
(cherry picked from commit 15be04f7a2)
This just moves the code over to ci/github-script to make it easy to
test and iterate on locally.
The name `prepare` is chosen, because the script will be extended with
the other steps from "PR / prepare" next.
(cherry picked from commit c787c66de6)
This action will not be called for push events anymore. For those, the
`push.yml` workflow is run instead, which hardcodes `mergedSha`.
(cherry picked from commit 2087f1be30)
This was an oversight when we introduced the ability for
`get-merge-commit` to take the pre-computed sha as input.
(cherry picked from commit f5c5bc25ea)
Introduces a basic merge queue workflow to initially only run lints.
This will avoid accidentally merging changes which break nixfmt after
its recent update to 1.0.0.
(cherry picked from commit 04c039f993)
