[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Enabling GitLab CI
From: |
David Kastrup |
Subject: |
Re: [RFC] Enabling GitLab CI |
Date: |
Thu, 21 May 2020 18:25:14 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Jonas Hahnfeld <address@hidden> writes:
> Am Donnerstag, den 21.05.2020, 17:10 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <address@hidden> writes:
>> > Am Donnerstag, den 21.05.2020, 15:19 +0200 schrieb David Kastrup:
>> > > Jonas Hahnfeld <address@hidden> writes:
>> > > > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup:
>> > > > > The "traffic jam" problem could be avoided by retaining the option of
>> > > > > pushing to staging. That would occur without CI, but one could
>> > > > > occasionally trigger the merge with CI on staging to have everything
>> > > > > in
>> > > > > it migrate to master. Since staging would be used by the more
>> > > > > experienced people desiring to bunch their work before testing, the
>> > > > > triggering could also happen manually by whoever thinks he has pushed
>> > > > > enough stuff to staging to give it a whirl.
>> > > >
>> > > > That's not really how CI works. With our policy of FF merges, what
>> > > > happens if some MR get merged directly to master and some sit in
>> > > > staging? You'd probably rebase staging which triggers another CI
>> > > > pipeline and doesn't buy you much.
>> > >
>> > > It buys you that several commits are bunched in staging and are treated
>> > > in bulk. At least I think it does.
>> >
>> > No, it doesn't: The MRs must pass CI individually before it can be
>> > merged.
>>
>> I did not propose to have CI on staging.
>
> In the current proposal, CI tests those merge requests that target
> master. If we allowed others targeting staging without CI, we would be
> unable to rely on automated testing.
The automated testing would be done upon asking Gitlab to merge staging
into master.
> If we think contention will be a problem, we cannot do the proposal.
> There's no sane "mixed bag": As outlined initially, we would 1)
> require CI for merge requests, and 2) disable direct pushes to
> master. This includes patchy which has no special permissions as far
> as GitLab is concerned.
Sure, it would be the merge request of staging to master that would
trigger the CI then.
> FWIW I don't see much contention at the current rate of development.
Well yes. And if there were much contention, we'd not likely stay in
the free plan for CI anyway.
> See also my other reply to Han-Wen.
--
David Kastrup
- Re: [RFC] Enabling GitLab CI, (continued)
- Re: [RFC] Enabling GitLab CI, Jonas Hahnfeld, 2020/05/23
- Re: [RFC] Enabling GitLab CI, David Kastrup, 2020/05/21
- Re: [RFC] Enabling GitLab CI, Jonas Hahnfeld, 2020/05/21
- Re: [RFC] Enabling GitLab CI, David Kastrup, 2020/05/21
- Re: [RFC] Enabling GitLab CI, Jonas Hahnfeld, 2020/05/21
- Re: [RFC] Enabling GitLab CI, David Kastrup, 2020/05/21
- Re: [RFC] Enabling GitLab CI, Jonas Hahnfeld, 2020/05/21
- Re: [RFC] Enabling GitLab CI,
David Kastrup <=
- Re: [RFC] Enabling GitLab CI, Jonas Hahnfeld, 2020/05/21