Fix the dep-updating workflow

[Smaug123]

No description provided.

[smaug123-robocop]

🤖 Code Review Complete

Commit: d055031

Summary

• .github/workflows/dependabot-nix-deps.yaml: The workflow now triggers on on: pull_request, but it relies on repository secrets in the new step:

  uses: actions/create-github-app-token@v3
  with:
    app-id: ${{ secrets.DEPS_UPDATER_CLIENT_APP_ID }}
    private-key: ${{ secrets.DEPS_UPDATER_PRIVATE_KEY }}

  For Dependabot PRs, pull_request-triggered runs commonly do not receive Actions secrets, so this step (and therefore checkout/push) will likely fail. If you need to generate a token/push back to the PR branch, you may need a different trigger strategy (e.g. pull_request_target with a carefully controlled checkout/execution model, or a workflow_run-based approach).

Reasoning

Main functional concern: switching this workflow from pull_request_target to pull_request while adding a GitHub App token generated from repository secrets is very likely to break the workflow for Dependabot PRs.

GitHub intentionally treats Dependabot-triggered workflow runs as untrusted: for pull_request events they typically get a read-only GITHUB_TOKEN and do not receive repository Actions secrets. In this workflow the new Create token step depends on secrets.DEPS_UPDATER_CLIENT_APP_ID and secrets.DEPS_UPDATER_PRIVATE_KEY. If those secrets are not provided (common for Dependabot PR runs), actions/create-github-app-token won’t be able to mint an installation token, and then checkout/push won’t work.

The rest of the changes (using the app’s bot name/email, fetching the bot user id via gh api, reducing GITHUB_TOKEN permissions to contents: read) are internally consistent assuming the app token can be created and has contents: write on the repo.

---

Robocop v3c49f530 | Batch: batch_69bc5f5b14e88190b6f0abdfdf1fce9e