Staging with Github Actions

Setup

We've recently introduced the possibility to stage pull-requests with Github Actions, on our main repo 🎉

You can stage to any of our staging servers:

• au-staging accessible on https://staging.openfoodnetwork.org.au/
• fr-staging accessible on https://staging.coopcircuits.fr/
• uk-staging accessible on https://staging.openfoodnetwork.org.uk/

To achieve this, you'll need:

• a Github account
• read access over the openfoodnetwork repository

Triggering a Workflow

After logging into Github, there are two ways you can trigger a staging workflow.

i) By adding a pr-staging-* label to the PR

• visit the URL of the target PR, like https://github.com/openfoodfoundation/openfoodnetwork/pull/<pr_number>
• and click the wheel from the Labels section, selecting one of the pr-staging-* labels:

You can check if the workflow trigger was successful, by visiting the Github Actions tab, and finding the a running workflow for the PR:

ii) Via the Actions section

As above, visit the Actions section, and:

1. click Deploy to Staging
2. click on the Run Workflow dropdown
3. select a branch or a tag
4. select a staging server
5. click Run workflow

If you've selected Branch: master, you can also add a has from a specific commit, in the Commit Reference field.

Guidelines on Staging

But before you stage, follow the checklist to prevent conflicts:

• Check that nobody else is using the staging server you want to use. For example for Australian staging server, make sure that no other people is using it by checking the pr-staged-au label pull request is staged.
• Check that the pull request is approved, in the Test Ready column and has no test failures or merge conflicts.
• Let others know that you are staging it by commenting on the #testing on Slack, if you have not used the label to trigger the workflow
• If you wish to use a staging server without triggering a workflow, please use the labels pr-no-staging-*; these won't trigger staging workflows, but will serve to signal to others on the team that the server is being used.

What happens technically

• The pull request and master are merged so that the result is staged and tested.
• The merge commit is pushed to the staging server.
• The server resets the database to its baseline data.
• A deploy script is run.

What to do when you've finished testing?

• If you are testing a PT, you can put your testing notes on the PR like usual.
• Then you can stage the next PR, without needing to wait for the previous PR to be pushed. Just remember to switch the staged label over.