GitHub Actions needed for in Nixpkgs

[FRidh]

There is a lot of work we could automate or improve automation for. For some of these tasks we have ofBorg, and others are already done using GH Actions.

This ticket lists tasks we could automate and the type of bot we need for it. By using GitHub Actions it is hopefully easier to get more people that are interested involved.

Backport pull requests (PR)

Backporting is a hassle. To do it correctly, one should wait until the original PR is merged and then cherry-pick -x. This is demotivating for contributors, especially in case of trivial cherry picks. Thus, we need a bot that backports as much as trivially possible.

The Action should check for the 9.needs: port to stable, although likely we should change the label to explicitly say the branch or NixOS version. The label needs to be set by a nixpkgs-committer.

• https://github.com/marketplace/actions/backporting. Note, however, it seems to have trouble with forks and does not allow you to use custom label names.

#124273

Check backports have a valid hash (PR)

The rule when backporting is to use cherry-pick -x so the hash of the original commit being cherry-picked is included in the new commit in the line `cherry picked from commit``. Sometimes this is forgotten, and sometimes the hash is simply incorrect, because the original was rebased instead of merged or the commit contents was simply changed.

NixOS/ofborg#437

Set labels based on issue and PR title and text (Issue/PR)

Based on the title as well as the fields in an issue and PR, we can set a bunch of labels.

• https://github.com/marketplace/actions/issue-auto-labeling-and-assigning

Set labels based on changed paths (PR)

Based on the paths that are changed by a PR, certain labels should be set. Note this is implemented currently by ofBorg https://github.com/NixOS/ofborg/blob/d39605727d9509826a61a4d38e18766a6a07277f/config.public.json#L116.

• Labeler: https://github.com/marketplace/actions/labeler

Comment on PR based on changed paths (PR)

Based on the paths that are changed by a PR, certain comments should be posted. An example are field-specific checklists.

• Changed files: https://github.com/marketplace/actions/get-changed-files

#113077

Invite maintainers to issue (Issue)

For the packages mentioned in the title and in the attributes field, invite the maintainers.

This requires an evaluation or at least a cache such as the packages-list file.

Merge master into staging branches daily

Mass-rebuilds should target staging and reach master via staging-next. To keep these two branches up to date, the master branch is merged into staging-next and then staging-next into staging. This is typically done daily and could be automated. Upon failure (merge conflict) a message is sent or issue opened.

Important is that these merges are not fast-forwards.

• https://github.com/marketplace/actions/merge-branch uses the GitHub API which does --no-ff.

Extends #99722.

[8573]

I feel I should note, before more GitHub Actions start being added, that, at least to my understanding, Actions configured with the default GITHUB_TOKEN, as seems common (e.g., all the Actions linked above say to use this token), have the equivalent of full push access (see, e.g., (1), (2), (3)), which most or all of these tasks shouldn't need. Per (1), one should be able to use a custom, more restricted token instead.

[lukegb]

I feel I should note, before more GitHub Actions start being added, that, at least to my understanding, Actions configured with the default GITHUB_TOKEN, as seems common (e.g., all the Actions linked above say to use this token), have the equivalent of full push access (see, e.g., (1), (2), (3)), which most or all of these tasks shouldn't need. Per (1), one should be able to use a custom, more restricted token instead.

I'm not actually sure it's that easy to drop permissions. You can overwrite the GITHUB_TOKEN environment variable, but it's still available as github.token context. In addition, using the provided GITHUB_TOKEN means you won't inadvertently trigger a GitHub Actions loop.

[DavHau]

I'd like to propose to add a shellcheck action for modified shell scripts only. I could make a PR if this is wanted.

[FRidh]

I'd like to propose to add a shellcheck action for modified shell scripts only. I could make a PR if this is wanted.

#105641

[8573]

@lukegb wrote—

I'm not actually sure it's that easy to drop permissions. You can overwrite the GITHUB_TOKEN environment variable, [...]

Is there a GITHUB_TOKEN environment variable? "GitHub Actions / Reference / Environment variables" doesn't seem to mention one; GITHUB_TOKEN seems to be a property of the secrets context.

[...] but it's still available as github.token context.

Available to a running action, if the author of the workflow (YAML file) doesn't provide it? I don't see that in the documentation, though it's very possible that I missed it.

[SuperSandro2000]

I did an action for auto updating nodePackages #112831. Feedback is appreciated.

[zowoq]

Set labels based on changed paths

#113077

[8573]

I feel I should note, before more GitHub Actions start being added, that, at least to my understanding, Actions configured with the default GITHUB_TOKEN, as seems common (e.g., all the Actions linked above say to use this token), have the equivalent of full push access (see, e.g., (1), (2), (3)), which most or all of these tasks shouldn't need. Per (1), one should be able to use a custom, more restricted token instead.

The year after I posted the above, GitHub added a permissions field to control the permissions granted through the GITHUB_TOKEN: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/. Adding this field seems easier than using a custom token.