Sometimes, I will want to push code, but I know it's not ready for a CI build yet. I really don't like polluting my commit messages with "tags" like [ci skip], and it wouldn't be clear to which commit I should add this tag anyway.
It would be much better if I could somehow tell GitLab, during the git push, to not create a build for this push event. This question on StackOverflow asks about passing arguments from git push.
While is of course isn't directly possible, this answer sheds some light on possible ways to accomplish this. The primary way would be via the target ref. Could we possibly "alias" ciskip/ref-name to ref-name, with the added effect of skipping CI build creation?
This would be very handful for the @gitlab-build-team when we want to build the EE package we usually push to dev, visit the pipeline pages, skip the build an then trigger through the API an ENV variable to signal we want an EE package build.
I had never heard of --push-option before, but if that works, it seems like a great solution. I hate polluting commit messages as well. And it's usually at push time that I think about whether I want to run CI or not.
As far as I can tell, there is no limit to the number of push options; I've tested up to ten.
GitLab integration
It seems like the most flexible implementation would be to collect the GIT_PUSH_OPTION_x env vars into an array in the pre-receive and post-receive hooks, and pass this in another parameter to all of the hooks:
In pre-receive:
GitlabAccess
GitlabCustomHook.pre_receive
In post-receive:
GitlabPostReceive
GitlabCustomHook.post_receive
I haven't yet tracked down which of these is responsible for triggering CI jobs (and thus handling the [ci skip] functionality).
@JonathonReinhart you need to expose the options to app/workers/post_receive.rb this is the entrypoint to process a push from GitLab's perspective. It's handed over from gitlab-shell (the hooks you mentioned above).
hooks/pre-receive
takes care of authorization and validations and (in EE) any custom hook.
here you can reject the push and it will be "rolled back".
it's from here that we block push to protected branches, for example.
hooks/post-receive
this is a point of no return, the "push transaction" is already commited.
you are just handing over data to GitLab or to any custom hook (in EE)
@brodock It looks like we were both fooled. It's not the /api/v4/internal/notify_post_receive API endpoint that queues the PostReceive job... The first thing that GitlabPostReceive.exec does is call update_redis which queues the PostReceive job.
So the push options will need to be pushed through redis to the Sidekiq job.
Somehow, pass this on to CreatePipelineService -- perhaps it is here that we actually look at the push options, and pass a ci_skip to CreatePipelineService, rather than all of the push_options
I would like to skip CI when a branch is force-updated to some older commit:
push 1: CI triggered: OK
push 2: CI triggered: fails
set branch back to 1 and push: CI should not be triggered
I can't do this with a commit message, because the message from 1 doesn't change. Is there a way to do this? Would the --push-option feature achieve this (when implemented)?
Is it unacceptable to skip the pipeline creation altogether (as my MR does), rather than creating a Skipped pipeline with no jobs (as [ci skip] currently does)?
There was recently a refactoring of the CreatePipelineService code and it's now going to be even more of a pain to get this down to the point where it needs to be.
I really would like to see this feature implemented. @JonathonReinhart is there anything I/we can do to help you get this over the finish line? Or if you don't have the time, perhaps somebody else can finish it up based on your work in !15643 (merged)?
/cc @markpundsack can we schedule this to an upcoming milestone so it doesn't disappear into ~"Community Contribution" purgatory ?
@mikegreiling I'd be happy to finish this (!15643 (merged)) up, but my current dev environment can't run all of gitlab-ce tests for some reason, so it needs rebuilt. Here's the question I had for some devs that remains yet unanswered:
Quick question: What Linux distro do you recommend for GitLab development? Do you recommend using the GitLab Development Kit? I plan to work on both gitlab-ce and gitlab-runner.
I had problems getting the GDK installed on Fedora due to dependency version problems. So, I'd like to just avoid those kinds of problems and install whatever distro the GitLab devs suggest.
@JonathonReinhart I would definitely recommend using the GitLab development kit to setup a development environment. Setting this up manually without it would be quite tedious and not very well documented.
As for supported distros, we do support Fedora >= 22 according to the docs for the GDK. However, I have not tried this myself and I'm not sure how many others use Fedora so it's possible docs may be out of date with respect to that environment. I can personally vouch for macOS (which I believe most GitLab engineers currently use), and Ubuntu. You can find setup instructions for each of our supported environments here:
The GDK didn't install on Fedora 27 because of an incompatibility with Ruby 2.3.6 and OpenSSL 1.1.x. Debian 9 (my preferred distro) also uses OpenSSL 1.1.x. But I see that you've since upgraded to Ruby 2.4.4 (!19055 (merged)), so maybe I'll give that another shot.