Template sync fails when changes are made to workflow files

[grst]

In a test-run, the template sync failed since apparently
the sync.yaml action is not permitted to make changes to files in the
.github/workflows directory:
https://github.com/icbi-lab/infercnvpy/actions/runs/3875431171/jobs/6607954535

This is a bit of a problem for which we still need to figure out a
solution. One of them is to use a personal access token. Another one
could be to centralize template sync, which I would have liked to avoid.

In #137, I roll back the changes made to workflow files since the last release,
as a short-term fix.

[Zethson]

Ohhh yeah I remember this. Think @Imipenem and myself also ran into this some years back. We went for a PAT

[ivirshup]

We just had a bad problem with CI (see discussion on zulip) and ended up needing to manually make the update PRs for 0.2.1. It would be nice to not have to do this.

@grst, could you go into some more detail on how the access token would work?

[grst]

• CI job runs in cookiecutter-scverse repo as cron job
• list of repos using the template (either from search API or registry)
  • handle opt-out one way or another
• for each repo, acting as scverse-bot
  • fork
  • clone
  • cruft update
  • create pull request

Here's a notebook doing that: https://gist.github.com/grst/d8d32f1d40b8dc84fd6fbe81d5df38c3

[ivirshup]

Ah cool, makes sense.

Where do we fork to, and where does the clone happen? Can this happen on github actions, or would that also be blocked?

Also, where does the token come into this?

[grst]

• fork to scverse-bot (or we make a dedicated account, e.g. scverse-template-update).
• This can absolutely happen on github actions (you just need to store the bot access token as a secret as we are already doing e.g. for syncing the cookiecutter-scverse-instance repo)
• to create PRs on other repos (afaik) an access token is required (rather than the anonymous $GITHUB_TOKEN available from github actions per default). Plus we need a namespace to fork to. Thus the need for a system account.

The difference is that

• previously, the action ran in the target repo, i.e. the running action has access to repository secrets (therefore the restrictions)
• now, we would be creating a fork. PRs from forks don't have access to secrets, therefore the restrictions don't apply.

[ivirshup]

Do either of you know how nf-core does this? It doesn't look like they make a fork.

• nf-core sync docs
• Example of sync event: Important! Template update for nf-core/tools v2.7.2 nf-core/rnaseq#909

It's not super clear to me if the repository has to be under the nf-core organization for this to work though.

I'm trying to find the code for the nf-core bot, and how it's triggered. Here's the code for the bot, but I'm still not sure how it's triggered or where that code runs.

[grst]

Afaik it's triggered upon a release of the nf-core tools package. And it only syncs repos within the nf-core organization using an access token that has commit rights to all repos.