[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 15:19:30 +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, 14:29 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <address@hidden> writes:
>> > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble:
>> > > On May 17, 2020, at 15:27, Jonas Hahnfeld <address@hidden> wrote:
>> > > > before merging. As we only allow fast-forward merges, this means each
>> > > > MR has received testing in the form it hits master. This would
>> > > > effectively replace the current setup of pushing to staging.
>> > >
>> > > I'm for this.
>> >
>> > Thanks. What do others (David, Han-Wen, Valentin) think about this?
>> > There's certainly room for improvement, but with an initial setup I can
>> > start writing documentation.
>>
>> 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.
> I don't mind deciding that we don't want to enable CI right now. The
> purpose of bringing this up now is that I didn't want to spend time
> documenting something that's going to change the next day. In my
> opinion, having CI and merging to master feels more "natural" than the
> staging setup. And finally if contention proves to be a problem, we
> can still revert to the old setup.
I was more going for the mixed bag right now :)
--
David Kastrup
- Re: [RFC] Enabling GitLab CI, (continued)
- Re: [RFC] Enabling GitLab CI, Dan Eble, 2020/05/19
- Re: [RFC] Enabling GitLab CI, Jonas Hahnfeld, 2020/05/21
- Re: [RFC] Enabling GitLab CI, Han-Wen Nienhuys, 2020/05/21
- Re: [RFC] Enabling GitLab CI, James, 2020/05/21
- Re: [RFC] Enabling GitLab CI, Han-Wen Nienhuys, 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/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 <=
- 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