search

TheDataShed / sql-deployment-tools

GNU General Public License v3.0
2 stars 0 forks source link

GitHub Actions Running too Frequently #49

Closed gvee-uk closed 2 years ago

gvee-uk commented 2 years ago

CI and CD stuff is running too frequently.

Ideally I think we want:

  1. Run CI when a PR is created
  2. Run CI when a PR is updated with a new commit
  3. Run CI when a PR is merged to main (note: not just closed, because that can include abandons)
  4. Run CD when CI for a merge to main has completed

Due to the running costs for Windows and MacOS (see #48 for instance) I think we should limit all CI elements to run on Linux agents only for now.

gvee-uk commented 2 years ago

A few initial musings:

  1. Official docs for running your workflow when a pull request merges
  2. Dependent jobs can be created using the needs options (see here for more information.
  3. Should we add on: workflow_dispatch to allow for manual running of CD workflows? If for whatever reason the CD actions fail then we might want the ability to manually kick things. Consider how this will work with (or against!) the cz bump stuff.
  4. The ** branch filter should probably be removed. I think this is what's triggering the double-running of stuffs.
  5. We should consider caching Python dependencies
  6. I'd be tempted to chain the CD side of things so that the more expensive runners (i.e. Windows and MacOS) run after the cheaper ones (i.e. Linux, then Windows, then Mac).
  7. Concurrency settings might be useful for the PR updates e.g. we could cancel any currently running CI run if a new commit is pushed.
GooseLF commented 2 years ago

I'd be happy using concurrency on the release builds since they only ever run off of the main branch and only run once the CI has finished successfully to trigger them. Reluctant to add cancel-in-progress to the CI as people working in different PR's wouldn't want to cancel out each other's builds E.G My code breaks the build, yours doesn't, other than commit message how do we tell who broke it?

gvee-uk commented 2 years ago

Reluctant to add cancel-in-progress to the CI as people working in different PR's wouldn't want to cancel out each other's builds E.G My code breaks the build, yours doesn't, other than commit message how do we tell who broke it?

I didn't realise that's how the cancel-in-progress worked. I has naively assumed it would work based on source branch or something.

Perhaps the group can be set to the name of the source branch?