3 ms·
There's also a third way called resource groups [1]. We use that to ensure that we only run the newest job if we have multiple deployment jobs waiting for execu
by tsak 3y ago
There's also a third way called resource groups [1]. We use that to ensure that we only run the newest job if we have multiple deployment jobs waiting for execution. This way even if we have multiple pipelines racing each other, only the last deployment job wins.
[1] https://docs.gitlab.com/ee/ci/resource_groups/index.html https://docs.gitlab.com/ee/ci/resource_groups/index.html
- imp0cat 3y agoYeah, we use that instead of dedicated runners, too. But it is a relatively new Gitlab concept, isn't it?
- tsak 3y agoWe've been using it for a year, as we often had the problem that somebody would push an update after an initial publish of a branch, not stopping the first branch and then two or more deploy jobs racing each other with unpredictable results.
- ranguna 3y agoI was a bit confused when I first saw this in the context of deployment jobs. If you go with oldest first and two or more prod jobs want to run, you are gonna have to wait for all the old deployments to finish unless you go to each one and cancel them, leaving only the latest one. This does prevent unorderd deployments from overwriting each other, but it's a pita. If you go with newest first, old deployments will overwrite new ones unless you toggle the setting to prevent outdated jobs from running, by which case you'll be locked out of doing a rollback unless you regenerate a whole old pipeline. It would make sense if they had a "newest only", where if you have one deployment running and 10 pending, by the time the current deployment finishes, gitlab would cancel all deployments except for the latest one. This way you don't have to wait for old deployments and you're free to do a rollback at any time. Bonus points if the cancelled jobs display a link to the latest job that was chosen from the queue.
- tsak 3y agoI've just checked our code, and we use `oldest_first`, not `newest_first`.
- sarki_247 3y ago> "It would make sense if they had a "newest only", where if you have one deployment running and 10 pending, by the time the current deployment finishes, gitlab would cancel all deployments except for the latest one. This way you don't have to wait for old deployments, and you're free to do a rollback at any time." Hi, GitLab Team member here. This is exactly how GitLab functions when you use "newest first" process mode [1] with Prevent outdated deployment jobs enabled [2]. By default, pipeline job retries for deployment rollback is enabled, you can rollback to any of the failed old deployments, except where its disabled. [3] [1] https://docs.gitlab.com/ee/ci/resource_groups/#process-modes https://docs.gitlab.com/ee/ci/resource_groups/#process-modes [2] https://docs.gitlab.com/ee/ci/environments/deployment_safety.html#prevent-outdated-deployment-jobs https://docs.gitlab.com/ee/ci/environments/deployment_safety... [3] https://docs.gitlab.com/ee/ci/environments/deployment_safety.html#job-retries-for-rollback-deployments https://docs.gitlab.com/ee/ci/environments/deployment_safety...
- ranguna 3y agoThanks for getting back to me! That's amazing, I always had this problem in my head about how to solve people stepping on each other's toes with high volume CD workflows. This should solve it nicely, thanks again!
- danpalmer 3y agoAh this is good. This had come in when I used it but I think the GitLab instance I used was a few releases out of date so wasn't available at the time.