The build container is unable to connect to service containers.
I’m using a mapped network drive and my build cannot find the correct path.
Docker executor: unsupported Windows Version.
Job marked as success and terminated midway using Kubernetes executor.
Job marked as success or failed incorrectly.
The service did not start due to a logon failure error when starting service.
How can I get colored output on the web terminal?.
I can’t run Windows BASH scripts I’m getting The system cannot find the batch label specified - buildscript.
b) Use NTFSSecurity tools for PowerShell.
I get a PathTooLongException during my builds on Windows.
I’ll try this and see if that is the problem. just after posting this, I found this FAQ entry, which indicates that the account may need the “SeServiceLogonRight” permission. Is there anyplace that the “gitlab-runner start” invocation would write out any more detailed information on what “did not start due to a logon failure” might have been? Or are there any suggestions? I tried gitlab-runner -debug start but it provides no additional info onscreen. The account/password syntax seems valid - any typos there causes the “install” step to fail with an “invalid account/password” message, so install must be doing a basic check on them. I thought it might be that this non-admin account couldn’t open a firewall port or something else runner needs to do, so I tried gitlab-runner install -user “OURDOMAIN\fred.flintstone” -password “slate”, but that also fails “start” with the same error, and I would have thought my admin account should have been able to provide anything the runner needed as well as the system account could. But the subsequent gitlab-runner start command throws the error “The service did not start due to a logon failure”. I tried installing runner for the day-to-day account with gitlab-runner install -user “OURDOMAIN\fred.flintstone” -password “bedrock” which runs successfully. One is a day-to-day account (call it “fred.flintstone”), which does not have administrator privileges on the machine. I have two accounts on this Windows machine that I could use which can access the file share. Unfortunately, this account does not have access to a necessary network-share drive managed by our Active Directory (call it “OURDOMAIN”), and IT indicates they would prefer not to alter this. This works, and I can successfully set up the runner (“shell”) and use it from GitLab CI jobs. If I do a simple default gitlab-runner install, it configures itself to use the built-in system account (“NT AUTHORITY/System”). I am trying to install gitlab-runner (11.4.2) on a Windows 7 Pro 64-bit machine.
0 kommentar(er)
