[petsc-dev] Gitlab workflow discussion with GitLab developers

[Patrick Sanan]

Very much agreed that the biggest sort of friction is dealing with MRs from
forks. I suspect that the reason many of the things we want don't work is
because they would be too dangerous to allow a random, possibly malicious,
user to do. E.g. setting labels seems innocuous enough, but all kinds of
workflows, including automated ones, could be based on them. A more likely
problem in our case is that someone could open an MR with
"workflow::Ready-to-Merge" because they guess that it means that from their
perspective it's ready (when to us it means more than that). It would be
easy for that to get merged before being reviewed.

So in asking about all this, maybe we should make sure that we understand
the privilege levels GitLab offers, as maybe we can address the usual case
that the outside person making an MR is a researcher or engineer that one
of us knows (of) and so has some degree of trust in, so there would be no
huge risk in giving them the ability to change labels etc.

(And my pet peeve is that my "todo list" is still swamped by "X set you as
an approver for Y".)

Am Fr., 21. Jan. 2022 um 06:53 Uhr schrieb Barry Smith <bsmith at petsc.dev>:

>
>
> On Jan 20, 2022, at 10:40 PM, Junchao Zhang <junchao.zhang at gmail.com>
> wrote:
>
> *  Email notification when one is mentioned or added as a reviewer
>
>
>    Hmm, I get emails on these? I don't get email saying I am code owner
> for a MR
>
> *  Color text in comment box
> *  Click a failed job, run the job with the *updated* branch
> *  Allow one to reorder commits (e.g., the fix up commits generated from
> applying comments) and mark commits that should be fixed up
> *  Easily retarget a branch, e.g., from main to release (currently I have
> to checkout to local machine, do rebase, then push)
>
> --Junchao Zhang
>
>
> On Thu, Jan 20, 2022 at 7:05 PM Barry Smith <bsmith at petsc.dev> wrote:
>
>>
>>   I got asked to go over some of my Gitlab workflow uses next week with
>> some Gitlab developers; they do this to understand how Gitlab is used, how
>> it can be improved etc.
>>
>>   If anyone has ideas on topics I should hit, let me know. I will hit
>> them on the brokenness of appropriate code-owners not being automatically
>> added to reviewers. And support for people outside of the Petsc group to
>> set more things when they make MRs. And being to easily add non-PETSc folks
>> as reviewers.
>>
>>   Barry
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220121/d90c276c/attachment-0001.html>