[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Enabling GitLab CI
From: |
Jonas Hahnfeld |
Subject: |
Re: [RFC] Enabling GitLab CI |
Date: |
Thu, 21 May 2020 19:01:55 +0200 |
User-agent: |
Evolution 3.36.2 |
Am Donnerstag, den 21.05.2020, 18:25 +0200 schrieb David Kastrup:
> > 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.
Interesting approach, I still had patchy in the equation. We'd still
need to target master initially so that James gets the CI results for
the countdown process. But this could be the easiest workaround in case
a developer with many patches hits contention and would be unable to
merge otherwise. I'm for keeping this in mind, but not making it a
rule.
signature.asc
Description: This is a digitally signed message part
- 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, 2020/05/21
- Re: [RFC] Enabling GitLab CI,
Jonas Hahnfeld <=