Hi Jeena, Tyler and others, Thanks for the reply!
I also have one other question: Will scap sync-file stay with us? There are also complex deployments handled outside of backport windows that I think might benefit from it, as it offers fine-grained control on what is happening. > 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). Good to know, thanks! I tend to +2 all backports at once, and decide on the deployment order during the window. This means patches getting merged in the "wrong" order will likely be an issue. Are backports in different repositories still an issue in that regard? For example, if I have three patches for three extensions, +2 them at once, and then use scap backport, will it sync everything, or will it only fetch submodules > 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. I meant the "Would you like to see the diff" step, but there are many scripts, and the "when to run the script" differs. Some have to be executed as the very first step (createExtensionTables.php, for example). Other scripts need to be executed as the very last step (purgeList.php). There are also scripts that are not much sensitive to when they run, they just have to run at some point. Martin út 27. 9. 2022 v 23:51 odesÃlatel Jeena Huneidi <[email protected]> napsal: > 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/
_______________________________________________ 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/
