POC: Combine slash-command-dispatch and conda-lock-command workflows

[weiji14]

Consolidate the slash-command-dispatch and conda-lock-command workflows into a single GitHub Action workflow, aided by the conda-lock-refresh GitHub Action at https://github.com/weiji14/conda-lock-refresh/releases/tag/v0.1.0

References:

• https://github.com/weiji14/conda-lock-refresh/tree/v0.1.0#usage
• https://github.com/weiji14/conda-lock-refresh-demo/blob/0f280e78657578326ba74d9f13861235661fb2d9/.github/workflows/conda-lock.yml
• Simplify condalock workflow to work without chatops pangeo-data/pangeo-docker-images#414

Closes #18, Supersedes #5

[github-actions]

👈 Test this PR on Binder

[weiji14]

This is the key part that ensures the workflow only runs on Pull Request comments starting with /condalock. Note that this can only run when the conda-lock-command.yml workflow file is on the default main branch (see https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment), so we'll need to merge this PR to test it.

For a demo of how this works, see weiji14/conda-lock-refresh-demo#6 (comment).

[weiji14]

We should be able to remove the secrets later, but best to keep it for a few weeks in case we need to revert this Pull Request due to some unforseen bugs.

[weiji14]

@yuvipanda or @scottyhq, appreciate it if either of you take a look at this PR and give it a review. The PR should be keeping the same functionality of the /condalock command as before, and is mostly just consolidating the slash-command-dispatch.yml and conda-lock-command.yml GitHub Action workflows into one workflow.

If not, I can also just merge this in first and sort out any problems later 🙂

[scottyhq]

Unfortunately these permissions don't seem to transfer to a fork such that the conda-lock step can't commit the lockfile (https://github.com/weiji14/conda-lock-refresh-demo/actions/runs/6176646925/job/16766044554).

[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Error: Process completed with exit code 128.

[scottyhq]

We worked around this originally by using a personal access token https://github.com/pangeo-data/pangeo-docker-images/blob/df4252f60bfc798f57323bdd86f0348ffce8fa4c/.github/workflows/ChatOpsDispatcher.yml#L13

[weiji14]

Yeah, I was afraid that the default GITHUB_TOKEN wouldn't work from forks. Really wanted to avoid the need for setting up a Personal Access Token if possible, because it would be a lot of work for 2i2c to configure this across 100s of repos.

I've also considered setting up a GitHub App instead which has more permissions (https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/deciding-when-to-build-a-github-app#choosing-between-a-github-app-or-github-actions), akin to what pre-commit CI is doing. That, or figuring out how conda-forge does it with their @conda-forge-admin, please rerender command (unsure if this is only scoped to within the conda-forge organization though).

[scottyhq]

This is neat @weiji14 I like creating a new action step. I think being able to run against forks is desirable for public projects. As far as I know the way to this is either to use a personal token or trigger the action from a label (which only repo admins can do & therefore the workflow can run with access to full secrets permissions) see https://github.com/uwhackweek/jupyterbook-template/blob/main/.github/workflows/netlifypreview.yaml

[weiji14]

This is neat @weiji14 I like creating a new action step. I think being able to run against forks is desirable for public projects. As far as I know the way to this is either to use a personal token or trigger the action from a label (which only repo admins can do & therefore the workflow can run with access to full secrets permissions) see https://github.com/uwhackweek/jupyterbook-template/blob/main/.github/workflows/netlifypreview.yaml

Agree that we want this to work for public forks too. I'm gonna see if there's a workaround for the permissions part, from https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#changing-the-permissions-in-a-forked-repository, it says:

You can use the permissions key to add and remove read permissions for forked repositories, but typically you can't grant write access. The exception to this behavior is where an admin user has selected the Send write tokens to workflows from pull requests option in the GitHub Actions settings. For more information, see "Managing GitHub Actions settings for a repository."

But that Send write tokens to workflows from pull requests option is only available for private repos 😅 There's another potential way which is to use the workflow_run event as mentioned at https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/#improvements-for-public-repository-forks, but that would require going back to two GitHub Actions YAML files (which might not be too bad if it doesn't require a PAT).

Let me have a think about what the best approach might be from all the options above. For this PR, I might end up sticking with tibdex/github-app-token to continue allowing forked repos to work with /condalock, and experiment with a non-PAT approach later in a follow-up PR.

[weiji14]

Let me have a think about what the best approach might be from all the options above. For this PR, I might end up sticking with tibdex/github-app-token to continue allowing forked repos to work with /condalock, and experiment with a non-PAT approach later in a follow-up PR.

Ok, using the GitHub App generated token again after 3046277 and 0c3a0ef.