- by using the same group (the workflow name), we should be able to
limit the concurrency to 1 execution, which might help with some
flaky tests we keep seeing
- now the vast majority of our flaky tests are gone, we don't need the
bigger machines
- however, browser tests seem to be a little slow, so we can try giving
them more power than the defaults
- this should also help with resource contention when we have multiple
jobs running at the same time, as we have double the numbers of
runners on the free machines
refs https://ghost.slack.com/archives/C02G9E68C/p1677753889082979
- Firefox tests have historically been flaky in CI and a real
distraction when developing
- Firefox is, unfortunately :(, not a widely used browser at only 2.9%
of global market share
- we've not had any Firefox-specific bugs that were detected in CI for
a very long time, so it doesn't add anything anyway
- given SQLite3 is only supported for development, we don't really care about
running tests on Node versions which aren't the recommended version
- this saves 2 jobs per CI run, which helps improve the health of CI in
general
- turns out our concurrency on these 8 core machines is only 10 jobs, so
everything is running really slowly
- by opening up to `linux`, we allow executions on 4, 8 and 16 core
machines with a total concurrency of 30
- we're seeing low availability for the 16 core machines and they might
be constrained as everyone jumps to the highest spec
- in theory, we don't need super fast multi-core machines to run tests,
so I'll try with 8 core ones
refs https://github.com/TryGhost/Toolbox/issues/488
- Node 18 is now LTS so we're adding support for it
- this adds Node 18.12.1 (the latest security release) to our supported
ranges and CI
refs: https://github.com/TryGhost/Toolbox/issues/481
* Correctly setup environment variable to run both local & staging browser-based tests
* Use non-production Ghost Admin build, since production builds require HTTPS to use Stripe Connect
- the create-release-branch workflow works by getting the most recent
tag, bumping it and using that to create the new tag
- now we've moved Portal into the monorepo, we've got two different
types of flags, but the Portal ones aren't valid semver so the
workflow fails if the most recent tag is one for Portal
- this fixes that by ensuring we only fetch tags matching the pattern we
use for tagging Ghost
- daily is a little to infrequent for us as it means new comments don't
cause the issue/PR to be unlabeled as `stale` for up to 24hrs
- this commit increases the frequency to hourly
refs https://github.com/TryGhost/Toolbox/issues/381
- when using `pull_request`, the workflow doesn't have permissions to
write to the PR in question
- there is another trigger - `pull_request_target` - but this comes with
a heap of security warnings
- our use of it should be OK because we're only checking out our own
Action and not code from the PR
- this commit also adds permissions to specify we only want write access
to issues and PRs
fixes https://github.com/TryGhost/Toolbox/issues/395
- we seem to be encountering issues with codecov where it randomly
reports huge jumps in test coverage %
- I'm still not sure of the reason why, but the general trend in CI with
codecov is to store test coverage files as artifacts and then submit
them to codecov in one go
- this commit implements that in our CI
- let's see if this improves anything
- we didn't clone the repo at the point when we were running a git
command, so that failed
- switched to a different method of checking out `main` and then
checking out the most recent tag
refs https://github.com/TryGhost/Toolbox/issues/381
- we want to start collecting events from pull requests so we can label
and reply upon certain events
- this adds the `closed` and `labeled` events to the workflow triggers
