I'm starting with gitlab CI.
I'm using Windows 7. I registred my GitlabRunner, but when I try to install it, I have this issue :
←[0;33mWARNING: Since GitLab Runner 10.0 this command is marked as DEPRECATED and will be removed in one of the upcoming releases←[0;m
←[31;1mFATAL: Failed to start gitlab-runner: The specified service does not exist as an installed service.←[0;m
Can you help me, please ? thnks :)
I found the solution, The service was launched by the Local System user, which does not add the Windows\system32 in the PATH.
I changed the user who launches the service to %username% of the session and it works :)
Sorry if I can't help. This issue seems to be happening in Windows and Linux as well.
I also received the following messages in the terminal:
Setting up gitlab-runner (10.0.0) ...
GitLab Runner: creating gitlab-runner...
WARNING: Since GitLab Runner 10.0 this command is marked as DEPRECATED and will be removed in one of the upcoming releases
gitlab-runner: Service is not running.
WARNING: Since GitLab Runner 10.0 this command is marked as DEPRECATED and will be removed in one of the upcoming releases
gitlab-ci-multi-runner: Service is not running.
WARNING: Since GitLab Runner 10.0 this command is marked as DEPRECATED and will be removed in one of the upcoming releases
WARNING: Since GitLab Runner 10.0 this command is marked as DEPRECATED and will be removed in one of the upcoming releases
Related
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,
We have just uninstalled Docker Community Edition and installed Enterprise Edition on a Windows Server 2016 System as per these steps.
On reaching the last step which is to test a hello-world container we are receiving the following error:
C:\Program Files\Docker\docker.exe: failed to register layer: re-exec
error: exit status 1: output: ProcessUtilityVMImage
\?\C:\ProgramData\Docker\windowsfilter\e345ad40cc8f7d073f62501b7445d42d677889c04b2c6fe0963ea6e092b52f95\UtilityVM:
The process cannot access the file because it is being used by another
process.
We are seeing lots of examples on SO related to other types of applications giving this error but not Docker.
How might we fix this?
This turned out to be an issue related to Symantec Endpoint Protection(SEP) clashing with Docker.
SEP needs to be upgraded to version 14 RU1 and several files need execution privileges.
Symantec posted a fix here: https://support.symantec.com/en_US/article.TECH246815.html which we have tried and worked.
I need to install GitLab on a server running Windows 7, but I'm blocked at this line. The documentation doesn't really helping me. The following is from my command prompt:
C:\GitLab-Runner>gitlab-runner.exe register
Please enter gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://gitlab.com
Please enter the gitlab-ci token for this runner:
Where can I find this token?
You're attempting to install the GitLab Runner which is used to run your jobs and send the results to a GitLab which is a server. As you're talking about GitLab running at a server you have to install that and not the Runner.
But it is not supported to install GitLab on Windows, see here in the GitLab forum. They recommend to use Linux in a virtual machine for that if you want it on Windows.
In all seriousness this is something that will probably never be supported.
Nevertheless to get the needed project registration token follow these steps described here. Also there is a discussion about it on GitHub.
To create a specific Runner without having admin rights to the GitLab instance, visit the project you want to make the Runner work for in GitLab:
Go to Settings ➔ Pipelines to obtain the token
Register the Runner
Further the process of registering the GitLab Runner which is actually what you're doing is described here.
I'm installing sonarqube on Windows Server 2012.
I have followed the following steps:
Downloaded sonarqube4.4 and extracted to C:\Sonarqube
Downloaded Java JDK 1.7.0_60 and jre 1.7.0_67 as well as jre7
Installed Windows SDK 7 and .NET Framework 4
Navigated to C:\sonar\bin\windows x86-64 and ran StartSonar.bat as an administrator, this ran ok with no output and Ihad to hot ctrl- Z to break
I then ran \windows-x86-64\InstallNTService.bat as an administrator and I am seeing the sonarQube services was launched, but failed to start.
Not sure what the problem is.
I believe you first ran \windows-x86-64\InstallNTService.bat successfully and then StartSonar.bat unsuccessfully (the inverse order of what you describe).
You probably have [this problem]: http://qualilogy.com/fr/wp-content/uploads/sites/2/2013/09/Sonar_ServiceLaunchError2.jpg
Windows could not start the Sonar service on Local Computer.
Error 1067: The process terminated unexpectedly.
In that case, the solution is to change the user/rights to launch the Sonar service: https://qualilogy.com/en/migrate-sonarqube-tomcat-to-windows-service/
Go to the Services window, find the Sonar service, and open the Properties windows to change the user it logs on as to one with sufficient permissions.
I was able to solve this problem by creating a new folder named “Temp” in C:\Windows\System32\config\systemprofile\AppData\Local\
The Log-File will show only
--> Wrapper Started as Service
Cleaning or creating >temp directory C:\Program Files (x86)\SonarQube\sonarqube\temp
<-- Wrapper Stopped
The SonarQube service was launched, but failed to start.
After a long search, I came up to this site http://zen-and-art-of-programming.blogspot.de/2013/03/installing-and-running-sonar-source.html.
Solution:
Navigate to C:\Windows\system32\config\systemprofile\AppData\Local\ and create the directory Temp
2: Set the user rights to full access
3: Run the StartNTService.bat
I'm trying to have the build agent run under another account than the build-in SYSTEM account. On our previous windows 2003 box this is no issue; just adding it to the buildAgent.properties and configuring the buildservice to run under the required account works fine.
However, on our server 2008 instalation the new setting is not picked up. Can anyone confirm changing this setting actually works on a server2008? / What else can I try?
Ok, I found the answer on the Teamcity forum here, apparantly it's a known issue and will be fixed in 7.1, but for now there are the following options:
install 7.1 EAP
run the agent using the console
apply a dirty, dirty hack in the registry
Upgrading from 7 to 7.1 resulted into a non-working TC installation so I opted for option 2:
To run the agent.bat we put a batch file in the Buildagent directory containing:
%windir%\system32\runas.exe /savecred /user:domain\user "%windir%\system32\cmd.exe /k D:\Teamcity\buildagent3\bin\agent.bat start"