[BUG] Fix openapi.json generation workflow #891
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #888.
Description
Apparently
github.event.pull_request.head.ref
isn't always guaranteed to exist on pull requests. The docs forEndBug/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 callactions/checkout
and thengit 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
Update
This PR doesn't actually trigger the workflow that updates openapi.json, but I've been trying it on #881:
github.event.pull_request.head.ref
, which doesn't exist sometimes:fetch-depth: 0
:fetch-depth: 0
: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 replacegithub.event.issue.number
withgithub.event.pull_request.number
, but then fails with a permissions error despite usingsecrets.GITHUB_TOKEN
with the permissions set toin the commit/push step.