determinatesystems / update-flake-lock Goto Github PK

I copy/pasted the first exemple from the README and see that it will always fail for a permission denied at the git push step.

Step to reproduce: copy/paste the exemple from the README and adjust it (here I point to version 19 of the action and I also activate the workflow when pushing on the dependencies_update branch:

name: update-flake-lock
on:
  push:
    branches:
      - dependencies_update
  workflow_dispatch: # allows manual triggering
  schedule:
    - cron: '0 0 * * 0' # runs weekly on Sunday at 00:00

jobs:
  lockfile:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
      - name: Install Nix
        uses: DeterminateSystems/nix-installer-action@v1
      - name: Update flake.lock
        uses: DeterminateSystems/update-flake-lock@v19
        with:
          pr-title: "Update flake.lock" # Title of PR to be created
          pr-labels: |                  # Labels to be set on the PR
            dependencies
            automated

Then push and see the error in the action execution output:

Pushing pull request branch to 'origin/update_flake_lock_action'
  /usr/bin/git push --force-with-lease origin HEAD:refs/heads/update_flake_lock_action
  remote: Permission to pgrange/hydra.git denied to github-actions[bot].
  fatal: unable to access 'https://github.com/pgrange/hydra/': The requested URL returned error: 403
  Error: The process '/usr/bin/git' failed with exit code 128

Here is the full action output: job 8691097940

Here is the workflow file for this particular run: dependencies-update.yaml.

Starting yesterday, the action fails to complete with the following message:

Create or update the pull request
  Attempting creation of pull request
  A pull request already exists for devusb:update_flake_lock_action
  Fetching existing pull request
  Attempting update of pull request
  Error: Cannot read properties of undefined (reading 'number')

Believe this is related -- looks like there may have been a breaking change to GitHub's PR API -- create-pull-request updated v6 to address it.

Currently, this bot includes the following in the PR:

Running GitHub Actions on this PR

GitHub Actions will not run workflows on pull requests which are opened by a GitHub Action.

To run GitHub Actions workflows on this PR, run:

git branch -D update_flake_lock_action
git fetch origin
git checkout update_flake_lock_action
git commit --amend --no-edit
git push origin update_flake_lock_action --force

A simpler way (both in terms of explanation and execution) exists, and the text could be:

Running GitHub Actions on this PR

GitHub Actions will not run workflows on pull requests which are opened by a GitHub Action.

To run GitHub Actions workflows on this PR, please close it and then reopen it again.

The README is confusing (or perhaps confused) about running the action on PRs.

## Example that doesn't run on PRs

If you were to run this action as a part of your CI workflow, you may want to prevent it from running against Pull Requests.

```yaml
name: update-flake-lock
on:
  workflow_dispatch: # allows manual triggering
  pull_request: # triggers on every Pull Request
  schedule:
    - cron: '0 0 * * 0' # runs weekly on Sunday at 00:00
...

AFAIU the comment is correct and that specification will trigger on every pull-request; while the section is about not triggering on pull-requests. I might not understand what the auther intended to say but the other examples don't have the on: pull_request: and will not trigger on PRs; so maybe this section is redundant.

Things like an editorconfig, README on how to contribute, etc. The thing that sticks out to me is writing down how contributors can test changes to the action.

Update automation is great when it runs on a regular basis. Let's have the default example run on a daily basis.

Either integrate the https://github.com/peter-evans/enable-pull-request-automerge project, or output the PR number such that this the enable-pull-request-automerge action can be tacked on after update-flake-lock

Currently, there is no way of telling whether an update happened, which means any following actions which rely on the pull-request-number output just get a PR number of 0 and fail.

      - uses: DeterminateSystems/update-flake-lock@v17
        id: update-flake
        with:
          branch: update-${{ matrix.flake }}
          commit-msg: "chore(flake/${{ matrix.flake }}): update"
          git-author-email: [email protected]
          git-author-name: hatesegfault
          inputs: ${{ matrix.flake }}
          pr-title: "chore(flake/${{ matrix.flake }}): update"
          token: ${{ secrets.PAT }}
      - uses: peter-evans/enable-pull-request-automerge@v2
        with:
          token: ${{ secrets.PAT }}
          pull-request-number: ${{ steps.update-flake.outputs.pull-request-number }}
          merge-method: rebase

Something like the above will fail whenever there's no update for matrix.flake. There should be a way to say if: ${{ steps.update-flake.outputs.updated == 'true' }} for follow-up steps.

It'd be nice to have a summary displayed when viewing an update workflow in GitHub Actions.

Currently it is possible to use the step outputs to print a basic summary manually, however it'd be nice if this was automatic and/or contained more (useful) information, such as what inputs (if any) were updated.

Is there a way to create separate PRs for each input being updated, instead of a PR including the updates of multiple inputs?

It could query locks.nodes.root.inputs in nix flake metadata --json, and then just individually update/create a PR for each one, perhaps?

Thanks for this action.

Unfortunately, since v11, the action now creates 2 commits: the flake update, and a second commit that commits pr_body.template and pr_body.txt. For example, see this PR:

hackworthltd/hacknix#560

(Unfortunately, I didn't notice this until after Mergify committed the PR.)

(I created that PR by running the action using a manual workflow, so perhaps that's related.)

Here's the resuable workflow we're using, for reference:

https://github.com/hackworthltd/.github/blob/main/.github/workflows/reusable-update-nix-flake-public.yml

Prior to upgrading to v11, it worked great.

Hello,

I'm using your Github action in my own workflow.

I noticed that when it is run through a pull-request, it doesn't work: loophp/flake-lock-update-workflow#5

The issue is:

  Error: When the repository is checked out on a commit instead of a branch, the 'base' input must be supplied.

Would it make sense to add some configuration to allow running the PR checks without extra manual steps, e.g. with one of the solutions suggested here:
https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#workarounds-to-trigger-further-workflow-runs

Personally I went for the GitHub App generated token, which worked very well.

Basically what is outlined here:
https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#authenticating-with-github-app-generated-tokens

So perhaps we could let users configure app_id and private_key and if they do, the necessary steps would be added.

Hopefully not a lot of people are using v1.1 explicitly, and v1.1 broke users of v1.

I use https://github.com/sellout/project-manager in most of my repos. It generates some files that get committed, and also adds a flake check that the files are current.

Using update-flake-lock often creates a PR that initially fails because the updated inputs cause changes in the generated files that then fail the up-to-date check.

I would like to be able to do something like

      - name: Update flake.lock
        uses: DeterminateSystems/update-flake-lock@main
        with:
          pr-title: "Update flake.lock"
          run: |
            nix develop --command project-manager switch
            git commit --all --message="Update generated files"

so that I don't have to manually update the PR with a new commit each time.

Most likely achieved by using https://docs.github.com/en/actions/learn-github-actions/workflow-commands-for-github-actions#setting-an-output-parameter

In order to sign commit with a subkey, crazy-max/ghaction-import-gpg requires the subkey finger print as input (details here).

Thank you for this project!
Is it possible to have this action update specific inputs?

Installer action comes with nix.conf options, different installers, etc.

One way would be to expose those via this action, but then what's the point of doing that? :)

what happens when you try to run update-flake-lock on a self-hosted github-runner on NixOS?

Run DamianReeves/[email protected]
Error: An error occurred trying to start process '/nix/store/d9hc30rhc1vqh5l659rz51ch5ki490bn-github-runner-2.311.0/lib/externals/node16/bin/node' with working directory '/run/github-runner/runner3/ds-research/ds-research'. No such file or directory

action items:

• make PR against DamianReeves/write-file-action to update node version
• update this action to include newer version of write-file-action

i'll see what i can find time to do, but thought it best to log an item here in case someone else gets around to fixing this before i do

thanks team 🙇‍♂️

Sometimes it is useful to create a secondary sub-flake which contains tests and their related dependencies so that they are not included in the top-level flake consumed downstream (i.e. to avoid polluting others' lock files with development dependencies).

It would be useful if the update-flake-lock action could update the root and sub flake in the same run/opened-PR and keep all inputs moving in lock step, rather than doing it across multiple runs

Hello there,

I upgraded to v5 today and it seems that there is something broken.

See a failing log here: https://github.com/loophp/flake-lock-update-workflow/runs/4416569613

Adding the possibility to use custom options to nix flake command could be useful.
For example, some of our flakes uses a private repositories so usually the access token is passed.

nix --access-tokens github.com=${{ secrets.GH_TOKEN }} ....

The current options does not seem to provide a way to pass custom options or flags.

The repo in question can be found here.

I am new to Github workflows, so I've probably done something wrong here. Here is the error:

In text:

  remote: Permission to alxpettit/httm-flake.git denied to github-actions[bot].
  fatal: unable to access 'https://github.com/alxpettit/httm-flake/': The requested URL returned error: 403

I have a repository in which I don't have control over the layout of files. Unfortunately the flake.nix file is not located at the root of the repository. Would it be possible to add another input to this action such that I could specify a path within the repository where the flake.nix is located?

I'm not sure how to manage automatic merging of PR. What is the 'proper' way of doing this?

Thank you, it works great!

But it seems that I need to add the script now to the root of my project.
Is that expected?

/home/runner/work/_temp/dd767b88-96e4-4375-8ba5-bd14e9de88d3.sh: line 1: ./update-input-or-inputs.sh: No such file or directory

If I add the script, then the action proceeds without problems.

Originally posted by @a-kenji in #14 (comment)

I don't know if there's an easy way to resolve this. Maybe it's not actually possible to break the logic out into a script.

As support for tokens is now allowed following #22, the section of the PR with Running GitHub Actions on this PR is not required when token is set, and its removal when the token is changed would be a nice UX improvement.

Is it possible to make it work with commit signing verification? In the previous link it's explained that of course bots can comply with this requirement. For security reasons this verification might be required in some protected branches in a repository, so without it this bot might not be usable in those repositories.

It seems that using something like this might work: https://httgp.com/signing-commits-in-github-actions/

Hi there, thanks for your work on this!

I'm currently attempting to use the update-flake-lock action within a private repo workflow that depends on two other private repos. I'm using SSH key pairs to provide access between repositories using webfactory/ssh-agent.

This works nicely for our regular CI build workflow, however our update-flake-lock workflow is failing at the update-flake-lock action with the following:

> Checking the base repository state
  /usr/bin/git symbolic-ref HEAD --short
  mitchmindtree/fix-update-flake-lock
  Working base is branch 'mitchmindtree/fix-update-flake-lock'
  /usr/bin/git remote prune origin
  ERROR: Repository not found.
  fatal: Could not read from remote repository.
  
  Please make sure you have the correct access rights
  and the repository exists.
  Error: The process '/usr/bin/git' failed with exit code 128

I'm wondering if perhaps the update-flake-lock does not have access to the ssh-agent for some reason?

Here's the failing workflow in question:

name: update-flake-lock

on:
  workflow_dispatch: # allows manual triggering
  schedule:
    - cron: '0 0 * * *' # runs nightly at 00:00 UTC

jobs:
  # Updates the pint-src flake input and open a PR with the updated flake.lock.
  lockfile:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: webfactory/[email protected]
        with:
          ssh-private-key: |
              ${{ secrets.SSH_KEY_BASE }}
              ${{ secrets.SSH_KEY_PINT }}
      - uses: DeterminateSystems/nix-installer-action@v10
      - uses: DeterminateSystems/update-flake-lock@main
        with:
          inputs: pint-src

Fwiw, here's our other workflow that is working and passing successfully. It's basically doing the same thing, but without using update-flake-lock. It at least shows that our SSH access is working elsewhere:

name: pint-nix

on:
  push:
    branches:
      - main
  pull_request:

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: true

jobs:
  # Check the default builds and dev envs work on both macOS and Linux.
  nix:
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, macos-latest]
        command: [
            "build --print-build-logs --no-update-lock-file",
            "develop --print-build-logs --no-update-lock-file",
          ]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: webfactory/[email protected]
        with:
          ssh-private-key: |
              ${{ secrets.SSH_KEY_BASE }}
              ${{ secrets.SSH_KEY_PINT }}
      - uses: DeterminateSystems/nix-installer-action@v10
      - uses: DeterminateSystems/magic-nix-cache-action@v4
      - run: nix ${{ matrix.command }}

Here is the full failing workflow log in case it helps:

workflow-log.txt

Perhaps we need to do something to forward ssh-agent access to update-flake-lock somehow? Or maybe this is a different issue I'm overlooking?

Any advice or ideas on what might be going on would be greatly appreciated 🙏

Wtih the frequency of NixOS channel updates, daily is quite a lot.

Would be nice to have a flag or option to enable the Signed-off-by line for the generated commit!

Hi, I am trying to update a flake which has a private flake as input:

{
  inputs.private.url = "git+ssh://[email protected]/org/private";
}

Is there a possibility to use this action to update private flake inputs? I guess the runner would somehow need ssh access to the remote repository.

This would be really nice to have, so I can recommend it for devenv.sh projects.

This action looks like it’s the natural replacement for https://github.com/knl/niv-updater-action when moving from niv to flakes.

One feature that I like a lot about niv-updater-actions is that it includes the relevant bits from the upstream git changelog in the PR description (and, somewhat related, it keeps updating the same PR until it can get merged, so if merging takes longer it will not create many PRs).

(It munges the changelog so that commit and PR references point to the right repo, and that they don’t spam upstream PRs with “this PR has been mentioned”.)

Would this be a useful feature for update-flake-lock as well?

If so, a possible (optional) extension would be to only lists those upstream commits that actually changed the derivation of the current flake’s outputs – useful when upstream has lots of unrelated changes, as nixpkgs tends to do, as outlined in https://discourse.nixos.org/t/bumping-flake-inputs-bisecting-input-repo-for-relevant-changelog-entries/25619/7?u=nomeata.