- 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
- our use-case for this is to ensure that people don't push to
`main` without running linting, as this can block CI from passing
until the linting issue is resolved
- however, it can become annoying to run linting on non-main branches,
especially when you just want to WIP some changes without caring for
linting
- generally speaking, anyone who creates commits on a non-main branch is
going to open them as a PR, so linting is run anyway
- this commit get the branch name and only runs linting if we're on
`main`
fixes https://github.com/TryGhost/Toolbox/issues/459
- in the situation where the `yarn dev` command fails, it pumps out a
massive error message, which is incredibly distracting to the dev
experience
- this changes the output to just be a log line with some suggestions on
how to fix it
- `refs/closes` can be confusing to those who are not familiar with GitHub when we actually mean "use refs or fixes (or closes)"
- we generally don't want to use emojis for alpha features because adding it to the release notes is unnecessary until the feature is GA
refs https://ghost.slack.com/archives/C02G9E68C/p1665497363885949
- we've seen an issue with `lint-staged` in the Admin package because it
doesn't pick up the lint-todo file, so it incorrectly flags linting
issues that we're ignoring
- this is happening because it runs the command from cwd, where the lint
exclusion file does not exist
- thankfully, `lint-staged` has `--relative` which will run the command
from the directory where the command is defined in config, so `ghost/admin`
in our case, and that means the lint file is present and picked up
- up until this commit, git hooks were only used by a handful of people
because they were a pain:
- they'd only be set up when you did `yarn setup`
- the existing hooks ran `yarn lint` on all projects, which was
incredibly slow
- as a result, not many of us actually had them enabled, but this would
cause issues in CI because people were pushing un-linted commits
- other JS projects tend to use husky to automate the git hook setup and
lint-staged to speed up linting on changed files
- this commit switches to using them both
- `lint-staged` only runs `eslint` on staged JS files that are about to
be committed - if there's a linting error, it will stop the commit
- I've configured the pre-commit hook to successfully exit in CI because we
don't want to run pre-commit hooks right now
- this means we can remove Grunt - yay!
- I lowered the code coverage on the repo to the point where
it started failing because I added a new export to the config library
- this wasn't easy to add tests for because the existing config tests
use the loader directly and not the library export
- instead, I'm just going to make the dev script access the loader, and
make a note to clean this up in the future when we pull out the config
module
- because the cwd of `.github/dev.js` is not `ghost/core`, it doesn't
pick up config.local.json files, so any configuration you set in there
isn't applied
- this meant that developers with HTTPS configured locally couldn't use
`--stripe` because it wouldn't configure the Stripe listening URL
correctly
- this adds an exports to the config lib to allow passing options in,
which I then utilize to pass the directory that config resides in
- this should fix the aforementioned problem with HTTPS
refs https://github.com/TryGhost/Toolbox/issues/426
- this adds support for `--portal` in `yarn dev` to support the upcoming
migration of Portal into the monorepo
- also adds the Portal folder to the ignorelist for nodemon so Ghost
doesn't bootloop
- 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
refs https://github.com/TryGhost/Toolbox/issues/426
- we're going to need to support more complex combinations of dev
commands soon, with other packages optionally running and env
variables being altered
- this command pulls out a lot of the dev env scripting into a single
scripts
- also cleans up the use of grunt-shell so we can remove the dependency
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
refs https://github.com/TryGhost/Toolbox/issues/395
- I think we regressed somewhere along the line here, but we seem to be
submitting two test coverage reports for the Admin tests and the unit
tests
- I'm not sure if this fixes the random issues we've been seeing with
-5%/+14% coverage bumps but it should clean this issue up first
- right now, we use an internal CI solution to create branches for patch
releases, but it's difficult to use
- this workflow should allow the team to create release branches from
the GitHub UI, without delving into our internal tooling
- this was originally added because we had an issue with a production
build of Admin during a release
- since then, we've got a canary build that runs for every commit on
`main`
- I think this test is superfluous now, so this commit removes it and
saves ~6 mins of CI time per commit
refs https://github.com/actions/runner-images/issues/6002
- Ubuntu 18.04 is now deprecated in GHA
- this commit moves all tests onto 22.04 except the Admin integration
tests because they're failing to pick Firefox up
- I can look into this after we've unblocked CI
- this required some reworking for the new monorepo setup, but this
commit should now enable the Ghost-CLI tests in CI again
- also switched upgrade test to v4 to support Node 16
refs 7913283c96
- you can supply a branch and a version to call it, and it'll produce a
zip of the tarball you can use
- this should avoid the need for local builds, which are error prone
- because of how the npm scripts were set up, we were running the full
Admin integration tests during the unit tests phase of CI
- this commit renames the majority of `test` to `test:unit` in the
package.json files, and aliases `test` to `test:unit`
- special packages like Admin have no-op'd `test:unit` scripts so we
don't end up running its tests
refs https://github.com/TryGhost/Toolbox/issues/365
- the .github/workflows/test.yml in Admin needed to be merged with the
top-level GHA folder so this test needed porting
- there is still the browser matrix testing to port once things are
stable
refs https://github.com/TryGhost/Toolbox/issues/354
- this commit turns the Ghost repo into a monorepo so we can bring our
internal packages back in, which makes life easier when working on
Ghost
