[BUG] Fix openapi.json generation workflow

[peytondmurray]

Fixes #888.

Description

Apparently github.event.pull_request.head.ref isn't always guaranteed to exist on pull requests. The docs for EndBug/add-and-commit suggest using this ref because otherwise the branch is checked out in a detached head state. A simple search for "how to add and commit in github actions" turns up a bunch of results that suggest that in fact you can just call actions/checkout and then git add .; git commit -m <message>; git push, so I'm not really sure who is right. The PR tests out the second approach.

Pull request checklist

• Did you test this change locally?
• Did you update the documentation (if required)?
• Did you add/update relevant tests for this change (if required)?

Update

This PR doesn't actually trigger the workflow that updates openapi.json, but I've been trying it on #881:

1. Checking out with the github.event.pull_request.head.ref, which doesn't exist sometimes:

      - name: "Checkout repository 🛎️"
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}

2. Not checking out specific ref:

        with:
          ref: ${{ github.event.pull_request.head.ref }}

3. Checking out with fetch-depth: 0:

        with:
          ref: ${{ github.event.pull_request.head.ref }}
          fetch-depth: 0

4. Checking out without a specific ref and with fetch-depth: 0:

        with:
          fetch-depth: 0

5. Checking out with github.head_ref:

        with:
          ref: ${{ github.head_ref }}

6. Checking out with fetch-depth: 0:

        with:
          ref: ${{ github.head_ref }}
          fetch-depth: 0

It seems like this might not be possible according to this community discussion, or it should be possible according to this, this, this, and this, but it's unclear if these work on PRs coming from forks. This suggests that I need to use a personal access token rather than the GITHUB_TOKEN generated during workflows, but would be suboptimal because we'd have to switch it out if whoever owns it eventually moves on from conda-store development. I thought about trying to do what pre-commit.ci does, but it's quite convoluted: its entrypoint is a js module which spawns a python subprocess (??) which clones and then copies your branch, then does a cherry-pick (???) to get the formatted changes in. This approach checks out correctly if I replace github.event.issue.number with github.event.pull_request.number, but then fails with a permissions error despite using secrets.GITHUB_TOKEN with the permissions set to

permissions:
  contents: write
  pull-requests: write

in the commit/push step.

[netlify]

✅ Deploy Preview for conda-store canceled.

Name	Link
🔨 Latest commit	a0b6a04
🔍 Latest deploy log	https://app.netlify.com/sites/conda-store/deploys/66ff04bcb0f141000874488f

[peytondmurray]

After a discussion with the conda-store team, it seems like fork permissions are quite difficult to get right. I'm changing this workflow to a once-a-week cron job which makes a PR to conda-incubator/conda-store to make this easier.

[peytondmurray]

Okay, with the new workflow I've tested on my fork with a workflow_dispatch event and all seems fine.

• Action: https://github.com/peytondmurray/conda-store/actions/runs/11169604674
• Resulting PR: [AUTO] Update openapi.json peytondmurray/conda-store#2

[soapy1]

LGTM 👍