zlacker

One of the things I like about Actions is how much it's focused on automation rather than CI. The pain points I've had with Circle/GitLab/Travis have often boiled down to the fact that they are often very specifically about _testing software_, not _automating processes_, and not even _deploying software_.

On that last one, there's a potential bug in the deployment pipeline here – deploys could run simultaneously or some bad luck on runner speed could even see an older version of the code go out after a newer version. Combined with the automated database migrations this could be quite a big problem!

Actions thankfully solved this recently with the `concurrency` key that lets you form a serial queue by a given key such as the branch name.

>>danpal+(OP)
I'm not sure the concurrency key can solve the issue of old code after new code, in the general case.

What happens if there are conflicting migrations on two "parallel" branches?

What happens in you bad luck situation when commits are pushed in rapid succession on the same branch?

>>danpal+(OP)
In GitLab you can limit concurrency by using a resource group https://about.gitlab.com/blog/2020/01/21/introducing-resourc...

Does that address your need?

Edit with more context: We use CI for deploying to GitLab.com and use resource_group to prevent multiple jobs from running concurrently. What we lack is the ability to prevent multiple pipelines from running concurrently (resource_group is at the job level). It looks like concurrency for actions https://docs.github.com/en/actions/reference/workflow-syntax... can work on groups which is a bit nicer. There is some discussion about making this better for GitLab in https://gitlab.com/gitlab-org/gitlab/-/issues/217522

>>danpal+(OP)
I've never felt like GitLab CI is more about testing software than anything else...

It's super flexible and you can do literally anything.

>>Philip+Es
Yeah, I concur with that, and what's more I find the documentation so much better - Actions is maybe just as flexible (and if it isn't frankly that might be an improvement!) but the docs are extremely lacking. I do prefer GH for just general look/feel/ease of use though.

>>verdve+w5
With the concurrency key at the top level, actions run it commit order.

As for running migrations on the same database from multiple branches, not a good idea. Probably best to decide on the branch that is the release branch (maybe main/master) and only deploy from that.

>>sytse+4d
While doing it at the job level is handy, doing it at the workflow or cross-job level is likely to become necessary as the complexity of the workflow scales. CircleCI has similar issues, syncing on one job can be done with a plugin, but cross-job sync never really works, and in our 10 step workflow where we have deploys queueing up in quick succession, we often find ordering issues.

GitHub Action's, Semaphore's, or even Jenkin's, concurrency primitives are pretty capable so I'd probably go with one of those.

>>Philip+Es
When I last used it (Aug 2020) seemed like they were trying to evolve out of a stricter build/test/release flow, like Travis, and into a looser/more general workflow system, like CircleCI. At that point, it felt like the workflows were a bit half-baked – getting caching right between workflow steps so that you could build a performant pipeline that didn't repeat unnecessary work was tricky if I remember correctly.

Apart from feeling like they were in that sort of transition, GitLab's docs were fine, better than Circle's, but I find GitHub Actions much clearer.