I have a gitlab-ci.yml file which I have inherited. And I have a local gitlab server running on my laptop. I have managed to create several gitlab runners and kickoff this inherited pipeline -- which gets immediately stuck. The error I am getting is:
...because you dont have any active runners online or available with any of these tags assigned to them: sometag
I have pieced together that the gitlab-ci.yml file references several tags and if there is a runner with a given tag, the runner will pickup my pipeline --- but why do I need this control (or hassle, more like it). What does it matter which runner runs my pipeline? Do i need to closely examine the gitlab-ci.yml file and based on that make some special runner for it ?
After I have modified my runners and gave them the missing tags, I am still getting the same error. Looking at the runner API results, the results do show that where it says "online" it shows "null". What does it mean? How do I make this runner "online"
There may be several runner, which will have different executors set up and thus, have different functionalities. So, the best practice is to give tags in gitlab-ci.yml file to run the jobs on particular runner.
In order to bring your runner online, you can go in the server where that particular gitlab runner is installed, and in the restart the gitlab-runner service using gitlab-runner restart with the user you have installed the runner or root user.
Sometimes, it might happen that you have changed the tags or added some tags to the runner using Gitlab UI but the same tags has not been saved in config.toml file. (config.toml file stores the gitlab-runner configurations. More details here https://docs.gitlab.com/runner/configuration/advanced-configuration.html)
So, in this particular case, you have to go the server where the gitlab-runner is installed, and modify the tags in config.toml file and then restart the gitlab-runner service. If everything goes well, you can see the runner is online in Gitlab UI.
Related
I'm using GitLab.com's managed CI runners, and I'd like to run my CI jobs using the if-not-present pull policy to avoid the extra minutes it takes to pull the image for each job. Trying to set that value in the .gitlab-ci.yml file gives me this error:
pull_policy ([if-not-present]) defined in GitLab pipeline config is not one of the allowed_pull_policies ([always])
This led me to the config.toml settings for restricting Docker pull policies, so I created a config.toml file at the root of my repository and tried that. However, I still get the same error.
Is config.toml only available for manual/self-hosted runners? Is there any other way to get past this?
Context
Image selection in .gitlab-ci.yml:
default:
image:
name: registry.gitlab.com/myorg/myrepo/ci/builder:latest
pull_policy: if-not-present
Contents of config.toml:
[[runners]]
executor = "docker"
[runners.docker]
pull_policy = ["if-not-present"]
allowed_pull_policies = ["always", "if-not-present"]
First of all, the config.toml file is not meant to be in your repo but on the runner machine (or container).
But anyways, the always pull policy should not cause image pulls to last minutes if the layers are already cached locally: it just ensures you have the latest version by checking the metadata. If the pulls take minutes, it means that either the layers are not available locally, or the image was actually updated (or that the connection to your container registry is so incredibly slow that just checking the metadata takes minutes, but that is unlikely).
It is very possible that Gitlab's managed runners do not have a way to locally cache layers, and thus there would be no practical difference between the always and if-not-present policies. For instance if you use Gitlab Saas:
A dedicated temporary runner VM hosts and runs each CI job.
(see https://docs.gitlab.com/ee/ci/runners/index.html)
Thus the downloaded layers are discarded as soon as the job finishes.
I configured a specific runner for gitlab-ci on a local server. It worked like a charm, and it is 3 times faster that the shared runner on gitlab.com. So far, so great.
But I was wondering what will happen if my local server was not available. In this scenario, all the jobs of the pipeline will be in pending (waiting to the specific runner). If so, all projects deployments could be stuck for a while.
I tried some configurations in .gitlab-ci.yml to run the shared runner if my specific runner was not available. But all my tests failed.
What I did
My idea was to set 2 tags for the runners. The first one for my specific runner and the second one for the shared runner.
.tags: &tags
- my-custom-runner
- shared
But in this configuration, if my-custom-runner was not available, I had this error in the gitlab-ci job :
this job is stuck because you don't have any active runners
Has anyone figured out how to do this yet ? I didn't find related documentation on this topic.
Any help will be welcome. Thanks a lot.
Additional information
This configuration works if my-custom-runner is available :
.tags: &tags
- my-custom-runner
This configuration works too and runs in the gitlab shared runner.
.tags: &tags
- shared
I'm new to Gitlab (and YML files, and just about everything else in this project ...), and want to add some script to the build pipeline to automate release file generation.
I added a few script lines to the branch's release section in gitlab-ci.yml, and can see they're generally doing what I want in the console output to the Gitlab UI. But, after a bit of head scratching I now realise the build itself is executed within a docker instance, which explains why I can't see the release file on the Gitlab host machine.
Is there a way of executing script from the YML file on the Gitlab host, as opposed to within the build container?
It depends on the executor type of the Gitlab Runner where the scripts are executed.
If the jobs are executed on a runner with a docker executor, each job will be run in a new container.
If the jobs are executed on a runner with a Shell executor the jobs will be executed directly on the runner machine.
BTW, it is not advised to have your runners on the same machine where you host your Gitlab server. Especially, runners with Shell executor. It compromises resiliency and scalability. A CI/CD job could break the entire host and make your gitlab server unavailable.
I am a beginner at the field of Devops.
I have created a simple web application (jsp), using 3 Jenkins jobs to store the code in GIT, to deploy the this app into Tomcat, and also to site-monitor this app (respectively).
Now, I have been trying - with no success -to automate a simple test with 2 verifications of my app functionality, using Selenium IDE and triggering it via Jenkins job (the fourth one in my project).
In order to perform it , I created the following job on Jenkins, with the needed plugin added (which is SeleniumHQ htmlsuite Run).
Here is the job:
https://i.stack.imgur.com/6Pm6a.png
The job running has failed,giving the following error which I cant handle.
When I run it, I get the following error :
https://i.stack.imgur.com/hXGmI.png
Any help would be very appreciated
Just tick Delete workspace before build starts box under Build Environment stanza
If you don't have the option in your Jenkins job configuration - make sure that Workspace Cleanup Plugin is installed
If you're running your Selenium tests via Jenkins Pipeline - all you need to do is to put cleanWS() directive somewhere in your pipeline code or Jenkinsfile
We upgraded from Gitlab 7.11.4 to 9 in one fell swoop (by accident). Now we are trying to get CI set up the way it use to run for us before. I understand that CI is an integrated thing now.
One of my coworkers got a multi-runner thing going. The running command looks like so:
/usr/bin/gitlab-ci-multi-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner
But previously we had 1 runner for each project and we had a user associated for each project. So, if we have 2 projects called "portal" and "engine", we would have users created thusly:
gitlab-runner-fps-portal
gitlab-runner-fps-engine
And being users, they would have home folders like:
/home/gitlab-runner-fps-portal
/home/gitlab-runner-fps-engine
In the older version of CI, you'd have a config.yml with the url of CI and the runners token. Now you have config.toml.
I want to "divorce" the engine runner from this multi setup which runs under user "gitlab-runner" and have its own runner that runs under "gitlab-runner-fps-engine".
Easy to do? Right now since all of this docker business is new to us, we're continuing on to use "shell" as our executor in gitlab, if that information is useful.
There are at least two ways you can do it:
Register a specific runner in each of the projects and disable the shared runners.
Use tags to specify the job must be run on a specific runner. This way you can have some CI jobs run on your defined environment while others (like lint for example) can be run on tagged shared runners.