I have two runners: one on Linux works fine, but one on Windows has problems that I try to solve. In order to know the current state of the runner I use two commands: verify and status. When I run verify:
>gitlab-runner.exe verify
outputs:
Verifying runner... is alive ←[0;m runner←[0;m=c6xxxxxx
while status
>gitlab-runner.exe status
outputs:
gitlab-runner: Service is not running.
Question
What is a difference between being alive and running?
PS
This questions is not about why it is not running, it is about understanding the status.
gitlab-runner version
Version: 10.6.0
Git revision: a3543a27
Git branch: 10-6-stable
GO version: go1.9.4
Built: 2018-03-22T08:34:34+00:00
OS/Arch: windows/amd64
gitlab-runner. exe status tells you, if the Service is running. It seems that you've stopped it with gitlab-runner.exe stop.
gitlab-runner.exe verify tells you if your Runner ist still registered to a GitLab Instance. If you or someone else removed it in the GitLab CI/CD settings, your Runner would'nt be alive anymore.
Related
I am facing a problem with the Build error on circle-ci.
this is my repo
Error
Build-agent version 1.0.41563-0e4d6629 (2020-10-22T11:30:36+0000)
Docker Engine Version: 18.09.6
Kernel Version: Linux 2e2f534dcc94 4.15.0-1077-aws #81-Ubuntu SMP Wed Jun 24 16:48:15 UTC 2020 x86_64 Linux
Starting container circleci/node:6.14.8
Warning: No authentication provided, this pull may be subject to Docker Hub download rate limits.
image cache not found on this host, downloading circleci/node:6.14.8
Error response from daemon: manifest for circleci/node:6.14.8 not found
6.14.8 is a really historic version. Are you sure you didn't mean 14.6.8, 14.8.6, etc.?
In order to see what versions CircleCI supports, see pre-built CircleCI Docker images.
You can also check official node versions you can pull at https://hub.docker.com/_/node
Off-topic: you're not authenticating your pulls. Docker is applying pull rate limit as of Nov 1st, so it would be a good idea to authenticate before the pull, see Docker auth on CircleCI for a tip.
I'm trying to unregister gitlab-runner on EC2 instance (Ubuntu machine) with the following command:
sudo gitlab-runner --debug unregister --token [RUNNER-TOKEN] --url [RUNNER-URL]
and I'm getting following error:
Runtime platform arch=amd64 os=linux pid=2374 revision=6fbc7474 version=13.1.1
Checking runtime mode GOOS=linux uid=0
Running in system-mode.
Dialing: tcp gitlab.com:443 ...
ERROR: Unregistering runner from GitLab forbidden runner=xv2Ng6Tc
FATAL: Failed to unregister runner
Make sure that you're using the entire SHA, not the partial one listed on the Gitlab CI runners list.
This can be found by running sudo gitlab-runner list on the machine with the runner installed.
If you've already removed the runner in the gitlab runners page, it will still be present on the gitlab-runner machine (check with the command sudo gitlab-runner list).
You can then unregister it from the config.toml using the command:
gitlab-runner verify --delete
Or manually, by running:
sudo gitlab-runner stop
sudo vi /etc/gitlab-runner/config.toml # update the runners section
sudo gitlab-runner start
For MacOS and Ubuntu
If you have already removed it from the Runners section in your project settings then you are no longer be able to unregister with command. Then what you can do is to delete them from your host as below:
gitlab-runner verify --delete
This will remove all the unregistered/removed runners from your host machine and will update config.toml file.
If you haven't removed it from Runners section in your project settings(Settings -> CI/CD -> Runners), then you can unregister it from your host like below:
gitlab-runner unregister runner_id/name
or unregister all runners,
gitlab-runner unregister --all-runners
Hope this will help to somebody. cheers !!!
I experienced the same issue when I tried to remove a runner that was removed directly from Gitlab settings of the project.
It seems that "Remove runner"'s button removes the runner from Gitlab but not from your gitlab-runner, which is absolutely fine since I don't want Gitlab to mess up to my on-premise gitlab-runner.
In order to fix that, I stopped the gitlab-runner service, removed the runner directly from the config file (it is usually located in /etc/gitlab-runner/config.toml) and started the service again.
I hope I could help you ;)
I ran into the same issue. I had to enter the right token in the config.toml file and boom, it worked: See this guide for more information: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4919. This solution is specifically for Windows, but can be applicable to Ubuntu as well.
If someone is still struggling with this like me, then here is something from docs: https://docs.gitlab.com/runner/commands/#gitlab-runner-unregister
gitlab-runner unregister --url http://gitlab.example.com/ --token <full_token_from_etc/gitlab-runner/config.toml>
I am writing a Jenkins pipeline aimed to pull a docker image from a private registry. At the moment I have an issue in launching the docker pull command, since it fails when launched from Jenkins.
Currently, the Jenkins pipeline works as follow:
takes a set of parameters from user (i.e.: image name and tag)
launches a separate bash script performing the pull operation.
The bash script does two operations:
logs in the registry through the following: echo $pwd | docker login -u$username --password-stdin $registryUrl
pulls the image through the command: docker pull $image:$tag
The login command succeeds, while the pull command replies with:
Error response from daemon: access denied:
no access to Image Load, on collection swarm
At first sight I think that's a matter of user privileges, but running the bash script outside the Jenkins context (as the owner of the jenkins process) it works.
Am I missing any configuration? As an alternative, I tried to implement the Jenkins pipeline using the Docker Jenkins Plugin API, but it fails too.
Final Note
The owner of the Jenkins process is different from the user logging in Docker private registry. May this affect the behavior?
Operating System:
macOS 10.14.6
Docker Version details:
Client: Docker Engine - Community
Version: 19.03.4
API version: 1.40
Go version: go1.12.10
Git commit: 9013bf5
Built: Thu Oct 17 23:44:48 2019
OS/Arch: darwin/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.4
API version: 1.40 (minimum version 1.12)
Go version: go1.12.10
Git commit: 9013bf5
Built: Thu Oct 17 23:50:38 2019
OS/Arch: linux/amd64
Pipelines have their own commands and tricks to login to dockerhub. For example,
docker.withRegistry('https://registry.hub.docker.com', 'dockerhub-creds') {
docker.image('myteam/secretimage:latest').inside() {
checkout scm
sh './configure && make && make test'
}
}
Here, dockerhub-creds are credentials you should create in Jenkins itself.
This technique is better than echoing password because:
Password will be hidden in build's stdout and from other users who don't have access to credentials
Password is magically mirrored across users, build nodes, docker containers etc and you will not face situation that "execution context is different, nothing works"
I recently install the gitlab-ruuner in a machine and register a specific runner manually with a registration token which obtained from CI/CD Setting/runner page for my repository by :
sudo gitlab-runner register
I start it by :
sudo -s gitlab-runner start
and output :
Runtime platform arch=amd64 os=linux pid=14558 revision=f100a208 version=11.6.0
The CI pipeline stuck in pending mode and requires a active runner assigned to it. How can I activate the runner?
I solved my problem. First I forgot to do sudo gitlab-runner run and after that I changed the config.toml. Specifically I turned privilege mode to true. And finally in the runner edit page, turn on the run untagged jobs option
If your CI/CD job is pending, saying This job is stuck, because you don't have any active runners that can run this job. Go to Runners page., try restarting your gitlab runner:
$ sudo gitlab-runner stop
$ sudo gitlab-runner start
If it is still not working, then try checking, if not yet, Run untagged jobs as below for your CI/CD runner, which by default is unchecked.
While setting up a Windows CI pipeline from GitLab, I was going through the numerous issues related to the Windows gitlab-runner docker executor that is using an old API (1.18) which Docker no longer accepts.
The issue results in the following error messages when the Gitlab/CI tries to connect to the runner:
Running with gitlab-runner 11.2.0 (35e8515d) on Windows VS2017 x64 0825d1d7
Using Docker executor with image buildtools2017 ...
ERROR: Preparation failed: Error response from daemon: **client version 1.18 is too old.** Minimum supported API version is 1.24, please upgrade your client to a newer version (executor_docker.go:1148:0s)
The 'buildtools2017' docker image that is referred to is the Microsoft "official".
The image seems to be working and valid for the current (experimental) Docker version I'm using (18.06.1-ce-win74) and for the stable version as well.
The issue was described throughout the GitLab wiki. Andrew Leech (?) went so far as to fork and modify the runner so that it would connect properly, and kindly provided his scripts and comments in a blogpost. This seems to give some results:
C:\gitlab-runner>gitlab-runner.exe -v
Version: 10.8.0~beta.551.g67a6ccc7
Git revision: 67a6ccc7
Git branch: windows-container-executor
GO version: go1.9.4
Built: 2018-07-30T08:57:44+00:00
OS/Arch: windows/amd64
The GitLab wiki states that they're waiting until a more stable solution can be released. Currently it's been over one year of broken windows docker runners..
Andrew's blogpost and a link to his gitlab-runner.exe describes actually a different workaround using the PowerShell runner that then starts a Docker instance. All the token info is exposed, I'm not sure how to set it up, and it also seems to rely on an external image with older build tools.
It seems the docker runner now connects, but if I undestand correctly, the Gitlab-runner docker runner does not seem to agree on the 'build directory' that is used. The first Gitlab/CI scriptline in my repo is just an echo command, so the error is not about the ci script content, but I'm not sure what it IS about. If anyone with docker fu knows what is going on this would really help me.
Using Docker executor with image buildtools2017 ...
ERROR: Preparation failed: build directory needs to be absolute and non-root path
Cheers,