-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: Improve github actions workflows #3235
Conversation
…artifact The "default" action now supports downloading from different workflow runs, too, so we might as well use it.
9018ee2
to
dce0c62
Compare
…ng main The previous setup would cause multiple commits on main to be stuck in a pending state, waiting for the previous run to be finished. The new group specification is taken from: https://docs.github.com/en/actions/using-jobs/using-concurrency#example-using-a-fallback-value This also adds the same settings for the docs workflow.
While this duplicates code a little bit, it makes it much simpler to refactor later on.
dce0c62
to
6cbd086
Compare
6cbd086
to
f110817
Compare
Both jobs run really quick, running them separate is just a waste of resources. Plus, they are semantically closely related anyway.
This TODO will have to wait until later. Will need to simplify the whole ARM job first, when our self-hosted GitHub Runner works. Too many dependencies between jobs in that area. |
The FreeBSD build is still executing when only the docs are changed. https://github.com/PostgREST/postgrest/pull/3296/checks?check_run_id=22142036339 Only FreeBSD, the rest is working perfectly. |
Right, I noticed a few days ago as well. I think it's somewhere on my list, but thanks for the reminder :) |
The goal of this PR is to make Pull Requests run only those jobs they need to run, i.e. a docs-only PR should only run the docs jobs. A PR only touching tests, should only run the test-related jobs, and a PR touching code should run both Build and Test jobs.
GitHub Actions only allows
paths
on the workflow level, thus to achieve this, I had to split the whole thing into multiple workflows. This comes with it's own set of challenges, though, because especially the release jobs need to wait for the other jobs to finish, so they can't just run in parallel. Also, artifacts need to be available from build to release. To achieve this, we are using "Reusable Workflows" - i.e. the build, docs and test workflows are now run on their own in a PR - but as a nested workflow on any push event.TLDR:
TODO: