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 <martin.urbanec(a)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 time
> Martin
>
> út 27. 9. 2022 v 23:05 odesÃlatel Tyler Cipriani <tcipriani(a)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.
>> ____
>>
>> 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 -- wikitech-l(a)lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-leave(a)lists.wikimedia.org
>>
>>
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
> _______________________________________________
> Wikitech-l mailing list -- wikitech-l(a)lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-leave(a)lists.wikimedia.org
>
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
--
Jeena Huneidi
Software Engineer, Release Engineering
Wikimedia Foundation