confused by multiple pipelines
Things get really confusing around here when multiple merge requests are pending and merge relatively close to one another.
For example here, those requests were merged, in that order:
- Nov 9, 2022 5:01pm EST !325 (merged) add my mastodon URL, hide my real name, refresh my bio
- Nov 10, 2022 6:10pm EST !327 (merged) Bump tor stable version to 0.4.7.11
- Nov 10, 2022 6:14pm EST !323 (merged) Fix donuts' twitter handle
- Nov 10, 2022 6:14pm EST !324 (merged) people mastodon_url: use rel="me"
- Nov 10, 2022 7:16pm EST !326 (merged) Update content/about/people/gaba/contents.lr
Note that they were, of course, created in a different order.
Some of those jobs were also pushed to prod, but not all:
- says "deployed to prod" on Nov 11, 2022 12:12am, but when you look at the environment, the prod deploy job was... canceled? https://gitlab.torproject.org/tpo/web/tpo/-/jobs/197494
- says "deployed to prod" on Nov 11, 2022 12:12am, job also says "canceled" https://gitlab.torproject.org/tpo/web/tpo/-/jobs/197494
- says "deployed to prod" on Nov 11, 2022 12:15am, job also says "canceled" https://gitlab.torproject.org/tpo/web/tpo/-/jobs/197494
- doesn't say "deployed to prod", it was pending deployment, but i was worried it would clobber the other jobs, so i hit "deploy to prod" and immediately canceled the job, so it now is canceled: https://gitlab.torproject.org/tpo/web/tpo/-/jobs/197494
- building, currently says "will deploy to prod"
I wonder if the cancel i did for MR !324 (merged) canceled all the other prod jobs? Is there only one prod deploy job?
What's really strange in there is that some of the changes were actually deployed in there. it looks like:
- my MR (!325 (merged)) was deployed: my name is changed in about/people
- the stable version was bumped (!327 (merged)), at least in download/tor
- donuts' twitter handle is correct (!323 (merged))
- ... buuut jim's change didn't get through (!324 (merged)), maybe that's because that one was explicitly canceled?
- naturally, gaba's change is not deployed yet, as it's still building
I'm not sure I like the deployment workflow. I think I'd prefer if the "merge" button would actually deploy the changes to prod. It's nice to have a staging site and all, but if we really want to do this, maybe we should merge changes in a staging branch, and then have a separate MR process to periodically merge that branch into prod?
Right now it's really strange to have multiple "manual" jobs waiting for approval, as it's kind of scary: I feel I don't know what's going to happen when I hit that button. Right now, jim's changes are not deployed: if I retry the job I canceled, what will happen? will it clobber other MRs? why not? how do i tell?
Where are the docs for this service? The service page point to this project homepage. That teaches me how to clone the repo or make a "Pull Request" [sic], nothing about pipelines or staging workflows. There's docs on how to develop for this website but they do not speak of this either.
I understand this might be a problem common to all web workflows, maybe this ticket belongs in the CI templates, in that sense. But this is less of a problem on other sites (say, status.tpo) where we have less high MR traffic like this, so I figured I would start with a very specific example like this instead.
Note that I did find the blog service docs which are more elaborate, and do mention the pipelines, but only briefly:
If the staging build passes QA, a deployment to production must be triggered manually via the Pipelines or Environments project pages
.. it doesn't mention what happens when there are multiple MRs in flight, or how to handle such situations.
thanks for any clarification!
/cc @lavamind