> > The majority of my deployments are config changes, not backports – can scap > backport deploy those as well?
Yes, I've primarily been using it for those :) Also, just want to echo the thanks above — the script is awesome! Kind regards, *Sammy* *(They/Them)* User:TheresNoTime <https://meta.wikimedia.org/wiki/User:TheresNoTime> *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.* On Wed, 28 Sept 2022 at 09:49, Lucas Werkmeister < [email protected]> wrote: > 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 < > [email protected]>: > >> 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 time >>> >> >> Good 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. >> >> Jeena >> >> On Tue, Sep 27, 2022 at 2:23 PM Martin Urbanec < >> [email protected]> 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 time >>> >>> Martin >>> >>> út 27. 9. 2022 v 23:05 odesÃlatel Tyler Cipriani < >>> [email protected]> 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. >>>> ____ >>>> >>>> More details (and a demo) inside Jeena Huneidi’s excellent write up >>>> <https://phabricator.wikimedia.org/phame/post/view/297/scap_backport_makes_deployments_easy/> >>>> . >>>> >>>> <3 >>>> >>>> – Tyler Cipriani (on behalf of the RelEngers <https://releng.team> who >>>> really >>>> do make dreams come true) >>>> Engineering Manager, Release Engineering >>>> Wikimedia Foundation >>>> _______________________________________________ >>>> Wikitech-l mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ >>> >>> _______________________________________________ >>> Wikitech-l mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ >> >> >> >> -- >> Jeena Huneidi >> Software Engineer, Release Engineering >> Wikimedia Foundation >> _______________________________________________ >> Wikitech-l mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> 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 -- [email protected] > To unsubscribe send an email to [email protected] > https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
_______________________________________________ Wikitech-l mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
