[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Run CI pipeline without a merge request

From: Jonas Hahnfeld
Subject: Re: Run CI pipeline without a merge request
Date: Mon, 29 Jun 2020 12:45:10 +0200
User-agent: Evolution 3.36.3

Am Samstag, den 27.06.2020, 19:05 -0400 schrieb Dan Eble:
> Is there a way to run a CI pipeline on a branch without creating a merge 
> request first?  It seems that some people are outsourcing their development 
> testing to GitLab, which I don't mind per se, but when there is an MR 
> attached to the branch, the pushes generate email noise.

I also find this annoying, and I already complained about this once. In
my opinion, every developer should develop and test locally until
satisfied to a degree that changes need external review, which
coincides with automated testing. Personally, I always value my own
time less than that of my reviewers because it's eventually my interest
to get a change in...

> GitLab provides instructions[1] that sound simple.  When I tried following 
> them with an old branch I just rebased, I got the message
>     The form contains the following error:
>         • No stages / jobs for this pipeline.
> Maybe there are environment variables unknown to me which I am supposed to 
> set.

I think this is due to our current CI configuration: Right now, jobs
are executed if and only if the commit is part of a merge request that
targets the master branch. In terms of .gitlab-ci.yml:
This matches the initial requirements where we wanted testing, in
particular *not* for every commit that is pushed to some branch.

So when you create a pipeline via the web interface, GitLab finds no
job to execute and reports the error. According to the documentation,
there are at least two ways to solve this:
1. Create a pipeline for every commit, but make them manual. This could
be very annoying because there will be many and it'll be hard to find
the one you're interested in.
2. Enable the jobs if $CI_PIPELINE_SOURCE == "web". This solves the
exact instance of this problem, but additional rules will be needed for
other triggers (API, schedule, ...).

I think 2 is fine right now, unless somebody sees an immediate need for
anything else.


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]