The majority of my deployments are config changes, not backports – can scap backport deploy those as well?
Kind regards,
Sammy
(They/Them)
Wikimedia Steward
A/CU/OS
Unless otherwise stated, all statements from this account are made in a volunteer capacity, and may not reflect the views of the Wikimedia Foundation.
This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email.
I also have a question. The majority of my deployments are config changes, not backports – can scap backport deploy those as well? I wouldn’t assume so based on the name, but Tyler’s email mentions operations/mediawiki-config…Am Di., 27. Sept. 2022 um 23:51 Uhr schrieb Jeena Huneidi <jhuneidi@wikimedia.org>:_______________________________________________Hi Martin, thanks for the feedback!I often +2 all backports at the start of the window (or even prior the window), because I want to save time. It enables me to deploy more patches than I would be able to deploy with scap backport +2'ing it each patch separately. I also parallelize some of the steps (such as, +2'ing a config patch during the sync step), which also saves a bit of time. How would I do this with scap backport? By +2'ing the patch manually, and then letting scap backport figure out its magic?Yes, you can do a +2 ahead of time and still use scap backport to do the remainder of the process, just be aware that if you do this and a patch ends up getting merged before the patch you are in the process of backporting with scap backport gets merged, then scap backport would end up syncing both patches at the same time (you will be given a warning and asked if you want to proceed).Also, I'd like to mention that many ordinary deployments currently require a script to run. How would that work in scap backport world? When it asks me for confirmation, I will wait, run the script, and then finish it, to ensure the script runs at the right timeGood question...Do you mean the confirmation after syncing to debug servers? I assume you'd need to run the scripts right after pulling the changes to the deploy server. If so we would need to add an additional step.JeenaOn Tue, Sep 27, 2022 at 2:23 PM Martin Urbanec <martin.urbanec@wikimedia.cz> wrote:Hi,Thanks for all the work on this project! I have some thoughts.I often +2 all backports at the start of the window (or even prior the window), because I want to save time. It enables me to deploy more patches than I would be able to deploy with scap backport +2'ing it each patch separately. I also parallelize some of the steps (such as, +2'ing a config patch during the sync step), which also saves a bit of time. How would I do this with scap backport? By +2'ing the patch manually, and then letting scap backport figure out its magic?Also, I'd like to mention that many ordinary deployments currently require a script to run. How would that work in scap backport world? When it asks me for confirmation, I will wait, run the script, and then finish it, to ensure the script runs at the right timeMartin
_______________________________________________út 27. 9. 2022 v 23:05 odesílatel Tyler Cipriani <tcipriani@wikimedia.org> napsal:_______________________________________________tl;dr: use `scap backport <gerrit url>` to deploy MediaWiki backports____There’s now a single step to deploy changes to Wikimedia’s production MediaWiki.🤯 An 85% reduction in command remembering!On the deployment host run:scap backport <gerrit url>
This works for any change to a live branch for mediawiki/core, extensions, skins, or operations/mediawiki-config.
____Engineering Manager, Release EngineeringWikimedia Foundation
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
--Jeena Huneidi
Software Engineer, Release Engineering
Wikimedia Foundation
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
--_______________________________________________Lucas Werkmeister (he/er)
Software Engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de
Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/