[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new procedure with GitLab CI
From: |
David Kastrup |
Subject: |
Re: new procedure with GitLab CI |
Date: |
Thu, 28 May 2020 03:03:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Dan Eble <dan@faithful.be> writes:
> On May 27, 2020, at 07:16, David Kastrup <dak@gnu.org> wrote:
>>
>> Now that we have the first "please get in line" merge that isn't
>> actually to any degree unusual, I get the suspicion that my previous
>> alternative proposal of pushing to a CI-less staging branch that then
>> uses CI to get to master will eventually become a reality.
>
> I wasn't much bothered by this round of merging.
>
> I wonder how the rest of you feel about having another developer click
> the buttons to rebase and merge your MRs?
If you refer to me doing that on Han-Wen's merge request, he actually
started his pipeline (with merge-to-master-when-finished) shortly after
mine and it ended up not being allowed to push because of requiring a
rebase after my merge request went through. So when I saw that I caused
his intended merge to fail (or rather, that he had not checked whether
my earlier started pipeline was a merging one), I restarted his pipeline
as a "courtesy" since the rebase was a trivial one. So it's not as much
that I as "another developer clicked the buttons to rebase and merge his
MRs" rather than that I forced GitLab to complete his explicit order.
For a trivial rebase, I don't see much wrong here but of course others
may see this as taking too much of a liberty here.
> Maybe we could adopt a convention that if you would object to that,
> you configure your MR so that you are the only one who is allowed to
> merge; and if you don't do that, then anyone who comes by at a time no
> pipelines are running would be free to start one. — Dan
I don't think it would be a good idea to start a pipeline on somebody
else's merge request without having an indication that they were going
to follow through with "Patch_push": Patch_push indicates no objections
from foreign review, but the responsibility for starting the final
pipeline/merge should really lie with the original submitter.
In this case, Han-Wen already made the decision but GitLab did not
complete it. And the patched area was not related to mine, either.
--
David Kastrup
- Re: new procedure with GitLab CI, (continued)
- Re: new procedure with GitLab CI, Dan Eble, 2020/05/23
- Re: new procedure with GitLab CI, Jonas Hahnfeld, 2020/05/27
- Re: new procedure with GitLab CI, Valentin Villenave, 2020/05/27
- Re: new procedure with GitLab CI, Jonas Hahnfeld, 2020/05/27
- Re: new procedure with GitLab CI, Valentin Villenave, 2020/05/27
- Re: new procedure with GitLab CI, Valentin Villenave, 2020/05/27
- Re: new procedure with GitLab CI, Jonas Hahnfeld, 2020/05/27
- Re: new procedure with GitLab CI, David Kastrup, 2020/05/27
- Re: new procedure with GitLab CI, Dan Eble, 2020/05/27
- Re: new procedure with GitLab CI,
David Kastrup <=
- Re: new procedure with GitLab CI, Dan Eble, 2020/05/27
- Re: new procedure with GitLab CI, Valentin Villenave, 2020/05/29
- Re: new procedure with GitLab CI, Han-Wen Nienhuys, 2020/05/29
- Re: new procedure with GitLab CI, David Kastrup, 2020/05/29
- Re: new procedure with GitLab CI, Jonas Hahnfeld, 2020/05/30
- Re: new procedure with GitLab CI, Jonas Hahnfeld, 2020/05/30
- Re: new procedure with GitLab CI, James Lowe, 2020/05/30
- Re: new procedure with GitLab CI, Jonas Hahnfeld, 2020/05/30