Re: [Tails-project] [Tails-dev] GitLab is now in production

Delete this message

Reply to this message
Autor: intrigeri
Data:  
Dla: The Tails public development discussion list
CC: Public mailing list about the Tails project
Temat: Re: [Tails-project] [Tails-dev] GitLab is now in production
Hi,

(keeping tails-project@ in the loop, because I don't know how to
resolve the tension between "not everyone who should read this is on
tails-dev@ so some of us prefer to reply on -project@" and
"tails-project@'s topic is explicitly documented to be for
non-technical matters so this sort of discussions may make it less
welcoming a place for those who are interested in non-technical
matters but not so much in technical details")

Cyril Brulebois (2020-05-29):
> intrigeri <intrigeri@???> (2020-05-29):


>> Known issues
>> ============
>>
>>  - Updates to repositories used to build our website (tails.git and
>>    any of its underlay repositories, such as mirror-pool.git) are not
>>    automatically propagated to our production website. Only sysadmins
>>    can manually propagate such updates.

>>
>>    So far I've been synchronizing tails.git's master branch to our
>>    production website at least once a day. If you need anything beyond
>>    that, ask me or tails-sysadmins@???.

>
> Alright! That was my main concern 1 or 2 hours into my transitioned
> Tails world, with an updated calendar that wasn't published, and the
> apparent lack of git hook getting run when pushing. If that's expected,
> all good.
>
> But that means I'll have to sync with sysadmins when publishing the
> release on Tuesday.
>
> Unless something could be cronned to run at least every hour or
> something like that? No pressure or absolute need, just thinking out
> loud.


JFTR, zen implemented a temporary trick that allowed kibi to
workaround this problem during the 4.7 release process.

>  * On MRs: “Comment” vs. “Start thread” → maybe make “Start thread” the
>    default if that's possible?


I could not find a way to configure this in GitLab.

I'd like to take it easy on this front.
Redmine had no comment threading feature, so:

- every time we use "Start thread", we get some extra benefits

- when we don't use "Start thread" (but should have), we're back to
Redmine experience, i.e. not a regression

>  * Probably for release managers mainly/only: How to massively
>    unsubscribe, and/or avoid auto-subscribing to issues when changing
>    metadata en masse? (Usual “move remaining issues to the next
>    milestone” step is likely the reason why I'm receiving bug mail for
>    many items I never touched.)


FTR, kibi and I discussed it further elsewhere and I'm working
on a different solution to this problem:
https://gitlab.tails.boum.org/tails/tails/-/issues/17747

>  * Avoid link to create MR when pushing a main branch (e.g. stable):
>    There's a “Show link to create/view merge request when pushing from
>    the command line” setting but it seems global, rather than
>    per-branch…


I've checked and only one branch (the "main branch" i.e. "master"
currently) won't display that link. I found no way to configure GitLab
to disable this behavior for other branches. That's a bit unfortunate.
Would you like to file a feature request upstream about this?

Cheers!