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.
Related
i got this error on windows server 2019 standard running docker and no idea how to solve it. Running windows container with process isolation. Memory is always max 40% (32Gb), CPU always below 20% and disks lot of space (250Gb free).
Running an official container like : docker run -d --rm -p 8080:80 --name test mcr.microsoft.com/dotnet/core/samples:aspnetapp
Got this error after extracting phase and start of container :
C:\Program Files\Docker\docker.exe: Error response from daemon: CreateComputeSystem ba698710f7bff4d46dce2ee65453b9da143195770b93cf82f8bb3818fca70174: Insufficient system resources exist to complete the requested service. (extra info: {"SystemType":"Container","Name":"ba698710f7bff4d46dce2ee65453b9da143195770b93cf82f8bb3818fca70174","Owner":"docker","VolumePath":"\\\\?\\Volume{61d19b2c-50e1-4dd5-9257-9c67998f1123}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\ProgramData\\docker\\windowsfilter\\ba698710f7bff4d46dce2ee65453b9da143195770b93cf82f8bb3818fca70174","Layers":[{"ID":"05435bc5-50b1-5044-9210-12d7ab180470","Path":"C:\\ProgramData\\docker\\windowsfilter\\84fc4324bf3d2de92b5f9c0a80e238bc3b3f1fdbe0fea13b7a35146069c21663"},{"ID":"3f1c6cd1-b66d-5d8d-aa2e-d11e489b74fe","Path":"C:\\ProgramData\\docker\\windowsfilter\\11d9c87c3490cf087488aaf21a3c88b45c68273ea270c6f850261583715cf241"},{"ID":"655918d6-84bb-5633-8bb2-981f3a29e3c6","Path":"C:\\ProgramData\\docker\\windowsfilter\\1f11a5340a1c13ef658355b9e30f7794ee398fb863105d6e18b48bd8a4687f79"},{"ID":"41893d4a-0704-50df-8f4e-41cad4480d3e","Path":"C:\\ProgramData\\docker\\windowsfilter\\36296cba828c68663184ddd5e75f5084ce59b755fcc9025845fe516782b2e243"},{"ID":"dc4a1317-f05d-5470-847d-d1e4bd029e6d","Path":"C:\\ProgramData\\docker\\windowsfilter\\8293bbc58e2c9c7da089187afd6cbf0e22b1bcb27cadc3e569542e324733ef82"},{"ID":"6f247d11-4160-56dc-9dbe-b40a4b67d151","Path":"C:\\ProgramData\\docker\\windowsfilter\\d9ba1e3f6cffcc5f69e2d2265a7539a0e4aff9b4f8f86e3edc3ff5b4026a584b"},{"ID":"5f54a86d-b6e0-5f1c-977d-dc7bba046d7e","Path":"C:\\ProgramData\\docker\\windowsfilter\\9beb006814b54bda1f7afa7a0f2870a4a970ef624ab6d2bffec4e27f2b749d6e"},{"ID":"03a39db9-584f-5d5b-8bbc-95883aa2af8b","Path":"C:\\ProgramData\\docker\\windowsfilter\\38ad1eb3b36d16eb77e6264daca47fad96080cb9596aa6aeb8c6d269ffbead89"},{"ID":"bffe53fb-2619-5d30-ae46-da6f759a87ed","Path":"C:\\ProgramData\\docker\\windowsfilter\\d4b5eaee9002c7b73dd7a72880c9caa3a39b7ef5c304b19e7c0a732c01b2a4bb"},{"ID":"aaec8c93-d215-59d6-99e2-001f38fa3ee3","Path":"C:\\ProgramData\\docker\\windowsfilter\\34ccac695ab1683cc21309e94c64110476d45b07b69b6956da9e795c31f6b815"}],"HostName":"ba698710f7bf","HvPartition":false,"EndpointList":["9070F572-5CDD-4CCE-8C7E-218F0BA2F221"],"AllowUnqualifiedDNSQuery":true}).
Server: Docker Engine - Enterprise
Engine:
Version: 18.09.11
API version: 1.39 (minimum version 1.24)
Go version: go1.12.12
Git commit: 6112046bc9
Built: 11/13/2019 07:49:53
OS/Arch: windows/amd64
Experimental: false
Go to registry,
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\NDIS\IfTypes\24
and set ifUsedNetLuidIndices to 01
and then restart the computer.
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 have the same problem.
I've tried to do all classical methods like regenerate images, clear cache, regenerate htaccess.. but nothing works...
PS version 1.7.6.1
Linux Server Information # 1 SMP Wed Aug 14 08:29:59 EDT 2019 x86_64
Server software version: Apache
The NGINX server is not present on the hosting service and there are no errors on the web service and PHP side.
The server vendor indicates:
Problem only happens with SSL
no error on the webserver side
no error on the PHP side using the native PHP7.1 version
Any idea to solve this issue???
Thanks
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,
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.