Finally found a somewhat decent way to handle the whole forked PR situation so that we can act on them… since GitHub Actions are pretty useful to many of us without that capability it is nice that this solution does solve most cases. It can also be somewhat simple for user to setup, but depending on the situation, not so easy on the developer side since you need to logically separate your app into stages.
Here is the general gist:
- Action runs like normal but detects if it is a read only environment
- When read only, I built a plugin for the Octokit library that serializes each request and tries to do a write action, if you rely on the return values from a given write request then you have to mock this and replace it when deserializing - which is the only more complex part of this flow.
- When running normally, everything completes as normal.
- When running read only, the plugin will package the serialized commands up and save them as an artifact with a specific key
scheduletask is run on the workflow on a cron job which will quickly look for artifacts for that workflow , deserialize, and complete any outstanding flows
- Delete the artifacts when done so we dont waste space
- The whole thing is intelligent so that it will only create artifacts if it knows the schedule task is actually running as well so it won’t create artifacts if nothing will be there to process and delete them.
Essentially to make it work, the user just adds the schedule task to the workflow and it automates the rest for them:
name: "lint" on: [pull_request] jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: bradennapier/eslint-plus-action@v3
name: "lint" on: schedule: - cron: '*/15 * * * *' pull_request: jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: bradennapier/eslint-plus-action@v3
The schedule task always run against your master codebase so its important to understand that the workflow must exist on your master branch and need to be there for the workflow to run the updated code if you change it.
All secrets are available to the workflow and full write access
You will no longer be able to operate on the branch easily in the schedule task since the
actions/checkoutwill have checked out your master branch. So in my case, I lint everything and serialize those results so that the schedule is not needing to do anything else. This may restrict some cases but generally there should be options.
Artifacts end up taking up long-term space of around 1Kb or less – and however much builds up before the sceduled task flushes them which should never last more than however long your cron is set for. As a bonus, those can be downloaded for debugging purposes nice and easy
I think most of this can be packaged up to be plug and play, although just getting it working was my main focus for the current build.
You can see the eslint runs successfully on forked PR here: