Gitlab docker on windows

WARNING: this container is under development and should not be considered stable.

There is a known issue with MSYS2-based programs that prevents certain git related tools from running. This issue may prevent some usage of this container.

gitlab-runner running in a windows container.

Start the docker container with your public key:

• REGISTRATION_TOKEN — token can be found at http://. /admin/runners
• CI_SERVER_URL — url is in the form http://. /ci
• RUNNER_TAG_LIST — comma separated list of tags to register with
• RUNNER_NAME — name to register the runner with
• RUNNER_EXECUTOR — see docs for executors (defaults to shell )
• RUNNER_SHELL — executor shell to use, see docs for options (default to cmd )
• CONFIG_FILE — config path override (generally not used)
• REGISTER_RUN_UNTAGGED — TBD
• RUNNER_REQUEST_CONCURRENCY — TBD
• RUNNER_BUILDS_DIR — override the build path
• RUNNER_CACHE_DIR — override the cache path

See the official gitlab-runner usage docs for more information on supported enviornment variables

Volume trouble with GitLab docker image on Windows

I’m trying to run official image gitlab/gitlab-ce:latest by docker on my Windows 10.
First I tried to run it like below and it worked.

docker run —detach \
—hostname gitlab.example.com \
—publish 443:443 —publish 8080:80 —publish 22:22 \
—name gitlab \
—restart always \
—volume /srv/gitlab/config:/etc/gitlab \
—volume /srv/gitlab/logs:/var/log/gitlab \
—volume /srv/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce:latest

But the problem was that changes in container were not saving. I found that the thing is in volumes. This attaching works only for Boot2Docker VM. Ok, I successfully shared my disk C:/ from host(Window) in docker settings(desktop application) and test it. Window’s folder shared and I can see files in test container.

Now I’m trying ti run gitlab image like this:

docker run —detach \
—hostname gitlab.example.com \
—publish 443:443 —publish 8080:80 —publish 22:22 \
—name gitlab \
—restart always \
—volume C:\Users\Public\Gitlab\config:/etc/gitlab \
—volume C:\Users\Public\Gitlab\logs:/var/log/gitlab \
—volume C:\Users\Public\Gitlab\data:/var/opt/gitlab \
gitlab/gitlab-ce:latest

And got this error on container:

Please help, what did I do wrong?

2 Answers 2

The hyperv filesharing mechanism does not support unix style file permissions. Because of this, the application encounters an error when it tries to assert that ownership is what it expects. I would guess that it tries to do a ‘chown’, followed by the following shell line that is described in your output:

Error message indicates that it is expecting the owner to be ‘git’, but it gets ‘root’ instead.

You have two major possibilities. You could try to configure/change the process running inside your container to handle the situation. That might be as simple as changing the configuration so that it expects ‘root’ instead of ‘git’. It may end up being much more involved than that. Your mileage may vary.

Your other option is to use a file system that does properly support unix style permissions and ownership. This would mean that you should switch to using a named volume, or switch back to using a host volume within the hyperv vm that Docker For Windows sets up. Either way, your files will reside in the VM instead of on your host’s file system.

I would recommend using a named volume in this situation. Just keep in mind that if you reset your Docker For Windows VM, any data in a named volume will be reset as well.

Install GitLab Runner on Windows

To install and run GitLab Runner on Windows you need:

• Git, which can be installed from the official site
• A password for your user account, if you want to run it under your user account rather than the Built-in System Account.

Installation

1. Create a folder somewhere in your system, ex.: C:\GitLab-Runner .
2. Download the binary for 64-bit or 32-bit and put it into the folder you created. The following assumes you have renamed the binary to gitlab-runner.exe (optional). You can download a binary for every available version as described in Bleeding Edge — download any other tagged release.
3. Make sure to restrict the Write permissions on the GitLab Runner directory and executable. If you do not set these permissions, regular users can replace the executable with their own and run arbitrary code with elevated privileges.
4. Run an elevated command prompt:
5. Register a runner.

Install GitLab Runner as a service and start it. You can either run the service using the Built-in System Account (recommended) or using a user account.

Run service using Built-in System Account (under directory created in step 1. from above, ex.: C:\GitLab-Runner )

Run service using user account (under directory created in step 1. from above, ex.: C:\GitLab-Runner )

You have to enter a valid password for the current user account, because it’s required to start the service by Windows:

See the troubleshooting section if you encounter any errors during the GitLab Runner installation.

(Optional) Update the runner’s concurrent value in C:\GitLab-Runner\config.toml to allow multiple concurrent jobs as detailed in advanced configuration details. Additionally, you can use the advanced configuration details to update your shell executor to use Bash or PowerShell rather than Batch.

Voila! Runner is installed, running, and will start again after each system reboot. Logs are stored in Windows Event Log.

Update

Stop the service (you need an elevated command prompt as before):

Download the binary for 64-bit or 32-bit and replace runner’s executable. You can download a binary for every available version as described in Bleeding Edge — download any other tagged release.

Start the service:

Uninstall

Windows version support policy

We follow the same lifecycle policy as Microsoft’s Servicing Channels.

This means that we support:

• Long-Term Servicing Channel, versions for 5 years after their release date. Note that we don’t support versions that are on extended support.
• Semi-Annual Channel versions for 18 months after their release date. We don’t support these versions after mainstream support ends.

This is the case for both the Windows binaries that we distribute, and also for the Docker executor.

After a Windows version no longer receives mainstream support from Microsoft, we officially deprecate the version and remove it in the next major change. For example, in 12.x we started supporting Windows 1803 because it came out on 2018-04-30 . Mainstream support ended on 2019-11-12 , so we deprecated Windows 1803 in 12.x and it was removed in GitLab 13.0.

As a single source of truth we use https://docs.microsoft.com/en-us/lifecycle/products/ which specifies both the release and mainstream support dates.

Below is a list of versions that are commonly used and their end of life date:

OS	Mainstream support end of life date
Windows 10 1809/2019	January 2024
Windows Server Datacenter 1809/2019	January 2024
Windows Server Datacenter 1903	December 2020

Future releases

Microsoft releases new Windows Server products in the Semi-Annual Channel twice a year, and every 2 — 3 years a new major version of Windows Sever is released in the Long-Term Servicing Channel (LTSC).

GitLab aims to test and release new GitLab Runner helper images that include the latest Windows Server version (Semi-Annual Channel) within 1 month of the official Microsoft release date. Refer to the Windows Server current versions by servicing option list for availability dates.

Windows troubleshooting

Make sure that you read the FAQ section which describes some of the most common problems with GitLab Runner.

If you encounter an error like The account name is invalid try to add .\ before the username:

If you encounter a The service did not start due to a logon failure error while starting the service, please look in the FAQ to check how to resolve the problem.

If you don’t have a Windows Password, the GitLab Runner service won’t start but you can use the Built-in System Account.

If you have issues with the Built-in System Account, please read Configure the Service to Start Up with the Built-in System Account on Microsoft’s support website.

Get runner logs

When you run .\gitlab-runner.exe install it installs gitlab-runner as a Windows service. You can find the logs in the Event Viewer with the provider name gitlab-runner .

If you don’t have access to the GUI, in PowerShell, you can run Get-WinEvent .

I get a PathTooLongException during my builds on Windows

This is caused by tools like npm which will sometimes generate directory structures with paths more than 260 characters in length. There are two possible fixes you can adopt to solve the problem.

a) Use Git with core.longpaths enabled

You can avoid the problem by using Git to clean your directory structure, first run git config —system core.longpaths true from the command line and then set your project to use git fetch from the GitLab CI project settings page.

b) Use NTFSSecurity tools for PowerShell

The NTFSSecurity PowerShell module provides a Remove-Item2 method which supports long paths. GitLab Runner will detect it if it is available and automatically make use of it.

I can’t run Windows BASH scripts; I’m getting The system cannot find the batch label specified — buildscript

You need to prepend call to your Batch file line in .gitlab-ci.yml so that it looks like call C:\path\to\test.bat . Here is a more complete example:

Additional info can be found under issue #1025.

How can I get colored output on the web terminal?

Short answer:

Make sure that you have the ANSI color codes in your program’s output. For the purposes of text formatting, assume that you’re running in a UNIX ANSI terminal emulator (because that’s what the webUI’s output is).

Long Answer:

The web interface for GitLab CI emulates a UNIX ANSI terminal (at least partially). The gitlab-runner pipes any output from the build directly to the web interface. That means that any ANSI color codes that are present will be honored.

Older versions of Windows’ CMD terminal (before Win10 version 1511) do not support ANSI color codes — they use win32 ( ANSI.SYS ) calls instead which are not present in the string to be displayed. When writing cross-platform programs, a developer will typically use ANSI color codes by default and convert them to win32 calls when running on a Windows system (example: Colorama).

If your program is doing the above, then you need to disable that conversion for the CI builds so that the ANSI codes remain in the string.

See GitLab CI YAML docs for an example using PowerShell and issue #332 for more information.

The service did not start due to a logon failure error when starting service

When installing and starting the GitLab Runner service on Windows you can meet with such error:

This error can occur when the user used to execute the service doesn’t have the SeServiceLogonRight permission. In this case, you need to add this permission for the chosen user and then try to start the service again.

1. Go to Control Panel > System and Security > Administrative Tools.
2. Open the Local Security Policy tool.
3. Choose the Security Settings > Local Policies > User Rights Assignment on the list on the left.
4. Open the Log on as a service on the list on the right.
5. Click the Add User or Group… button.
6. Add the user (“by hand” or using Advanced… button) and apply the settings.

According to Microsoft’s documentation this should work for: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, and Windows 8.

The Local Security Policy tool may be not available in some Windows versions — for example in “Home Edition” variant of each version.

After adding the SeServiceLogonRight for the user used in service configuration, the command gitlab-runner start should finish without failures and the service should be started properly.

Job marked as success and terminated midway using Kubernetes executor

Docker executor: unsupported Windows Version

GitLab Runner checks the version of Windows Server to verify that it’s supported.

It does this by running docker info .

If GitLab Runner fails to start with the following error, but with no Windows Server version specified, then the likely root cause is that the Docker version is too old.

The error should contain detailed information about the Windows Server version, which is then compared with the versions that GitLab Runner supports.

Docker 17.06.2 on Windows Server 1909 returns the following in the output of docker info .

The fix in this case is to upgrade the Docker version. Read more about supported Docker versions.

I’m using a mapped network drive and my build cannot find the correct path

If GitLab Runner is not being run under an administrator account and instead is using a standard user account, mapped network drives cannot be used and you’ll receive an error stating The system cannot find the path specified. This is because using a service logon session creates some limitations on accessing resources for security. Use the UNC path of your drive instead.

The build container is unable to connect to service containers

Network-per-build is required to use services with Windows containers. Ensure that the FF_NETWORK_PER_BUILD feature flag is set.