How to isolate a gitlab runner to process specific environment or stage - gitlab

I want to use gitlab runners for our builds and our deployment to QA. Can I set up a second runner that ONLY does deployments, or just a specific environment? I don't see a way to do this. (Gitlab.com/private runners)

Found it. This can be achieved using tags. CI runners can be configured to run only jobs that have specific tags, and tags can be applied to jobs.

Related

Cannot find how my jobs are bound to runners

I have a pipeline set up on Gitlab, within which my project is built and unit tests are run every time I commit a change to "developer" git branch.
Recently I've updated versions of some libraries in the project and after that builds on CICD started to fail and says that node.js version should be updated.
As I undestand I need to somehow edit settings of a container in which builds are run.
We have our own gitlab instance. As I see from the settings there are group of shared runners, used from many projects.
How can I find out which of those runners are used for my project? in the Gitlab GUI I can see tags assigned to the shared runners, but I don't see any tags in my .gitlab-ci.yml
Gitlab version is 15.4.2-ee
self-managed
If its not tagged it will run on any runner which is configured to run untagged jobs. Not just on any runner. By default runners don't run untagged jobs.

Scheduled pipeline in gitlab using .gitlab-ci.yaml file

I was trying to schedule a ci/cd pipeline in gitlab using .gitlab-ci.yaml file. I did't find a right documentation to implement the schedule using the ci/cd yaml file.
Is it possible to configure a pipeline run schedule (say everyday 08:00 AM) in .gitlab-ci.yaml file?
Thanks
Arun
Unfortunately, Scheduled pipeline is realized through GUI rather than .gitlab-ci.yml file in GitLab
You may find this document useful if you want to use GUI for schedule pipeline. Configuring in GUI is simpler than yaml coding.
If you really want it to be configured in yaml file, you may create an issue in GitLab repo. Actually, there's already an issue on this topic. It should not be a very difficult technically since it is only about keywords and parsing. Whether GitLab will do it or not is another story; so you'd better prepare a good scenario to persuade the GitLab team why you want this to be done.
The scheduled pipelines are configured via the GitLab CI/CD UI.
Read More about scheduled pipelines

How to add available shared runners to GitLab project?

Only one gitlab runner is available in my project. However, in the runner page I have multiple other runners listed. How do I add these runners to the project such that a runner will be randomly selected to execute the build? The runners are running in Docker containers and I am using a self-managed version of GitLab.
These are the runners I have available
Only runner1 is currently shown in /settings/cicd under Runners:
runner1
Basically, if you go by runners there are actually three types of a runner in Gitlab
Specific: Only for Specific Project
Group: For all projects in the particular group (if need more info on groups https://docs.gitlab.com/ee/user/group)
Shared: These will be available for every project in the GitLab
It will be difficult to specify here that how we can configure the runners but I can point to documentation from where we actually configured our Runners
https://docs.gitlab.com/ee/ci/runners/
Also to make a note of tagging is a very important task that needs to be done so that you can use your runners with your requirement like you said you want to use runners randomly from the list then all the runners in the list should have a common tag that can be further used in your .gitlab-ci.yml file.
eg. We have tag runners as per the AWS ec2 instance size so (like macro, small, medium, large, etc) so that people using can use the runners as per the requirement of there job)
job1:
tags:
- shared-large-runner
job2:
tags:
- shared-micro-runner
Note: you can have multiple tags for a single runner for better control over its usage.
Hopefully, this helps!!
Looking at your screenshot, to be able to use group runners, your project just need to be inside that group
Because the group tag shows that the runner was configured just to accept jobs from one group
I think you have one runner for each group, this is the reason that your project only have the runner1

Prevent Gitlab CI Runners from running tasks unless tagged

Gitlab jobs and runners can be tagged - so only runners with the tag can run the job. See documentation here: http://docs.gitlab.com/ce/ci/yaml/README.html#tags
I want to ensure that my runners that have tags only pick up tagged jobs. Currently jobs without any tags are eligible to run on these runners too.
Can this be done?
During the Registration process of the runner: https://docs.gitlab.com/runner/register/index.html
Choose whether the Runner should pick up jobs that do not have tags, you can change this later in GitLab's UI (defaults to false):
In the Admin panel https://<SERVER>/admin/runners
And in the config dialog of your specific runner (URL: https://<PROJECT_URL>/settings/ci_cd)
...you can set the option, to only run tagged jobs.
If you then also tag your jobs accordingly, you have reached your goal.
e.g.:
job:
tags:
- ruby
- postgres

where does job script run in gitlab ci?

Where does the Job script runs? Does it run on the same system as of Runner?
How the runner runs the script, and where does build get saved?
It would be great, if someone could explain the whole flow of Gitlab CI.
Yes, your jobs' scripts run on the same system as the runner. But before I go deeper, we need to discuss terminology. My team has run into issues before because the term 'runner' is overloaded. Humans typically use 'runner' to mean two different things:
A server on which the gitlab-ci exe is located
A gitlab-ci runner
The former should be self-explanatory; when you want to create a gitlab-ci runner, the first thing you do is provision a VM and put the exe on it somewhere.
The latter takes some explanation. gitlab-ci runners are not like Jenkins slaves; they're not entire servers. Instead, gitlab-ci runners act like a combination of workspaces and Jenkins labels. In other words, gitlab-ci runners combine a server, a gitlab instance, an execution environment and a set of tags. It is entirely possible, and in fact normal, to have multiple gitlab-ci runners on the same server.
The job script is completely decoupled from either type of runner (by 'job script' I assume you mean code called from a .gitlab-ci.yml file). Anything you call from that .gitlab-ci.yml, and in fact the script elements within it, will be executed
By a runner matching the tags configured for the job running the script
On the server on which that runner is installed
In a shell or Docker or Vagrant container, depending on the runner
Finally, the build is saved on the on which the runner is installed. the location will depend on the folder into which you dropped the gitlab-ci executable. Otherwise, jobs are stored on the file system in a manner reminiscent of Jenkins workspaces.

Resources