virtualmarc / gitlab-ci-runner-win Goto Github PK

For example, in the build result page in GitLab CI, it shows
C%3A%20%26%26%20cd%20C%3A%5CGitLab-CI-Runner%5Cprojects%5Cproject-1%20%26%26%20git%20reset%20--hard%20%26%26%20git%20clean%20-f%20%26%26%20git%20fetch

Using the CI Setting for Git clone or git fetch

I'm seeing what I believe is the build thread crashing with an exception (System.IO.PathTooLongException in this case), and the GitLab CI Build page simply shows the build as 'pending' forever, never realizing that it has failed.

Hello,
I tried to compile using Visual Studio 2015 with Windows 8.1 Pro. The binaries are created.

1>------ Rebuild All started: Project: gitlab-ci-runner, Configuration: Debug Any CPU ------
1>  gitlab-ci-runner -> C:\Users\sso\Downloads\gitlab-ci-runner-win-master\gitlab-ci-runner\bin\Debug\gitlab-ci-runner.exe
2>------ Rebuild All started: Project: runner.Build.success.test, Configuration: Debug Any CPU ------
2>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "ServiceStack.Text". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
2>  runner.Build.success.test -> C:\Users\sso\Downloads\gitlab-ci-runner-win-master\runner.Build.success.test\bin\Debug\runner.Build.success.test.dll
========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========

Then I run the application, located in gitlab-ci-runner\bin\Debug.
When I enter my CI URL, I get the following message.

Exception non gérée : System.ComponentModel.Win32Exception: Le fichier spécifié est introuvable
   à System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
   à gitlab_ci_runner.helper.SSHKey.generateKeypair() dans C:\Users\sso\Downloads\gitlab-ci-runner-win-master\gitlab-ci-runner\helper\SSHKey.cs:ligne 33
   à gitlab_ci_runner.setup.Setup.run() dans C:\Users\sso\Downloads\gitlab-ci-runner-win-master\gitlab-ci-runner\setup\Setup.cs:ligne 32
   à gitlab_ci_runner.Program.Main(String[] args) dans C:\Users\sso\Downloads\gitlab-ci-runner-win-master\gitlab-ci-runner\Program.cs:ligne 37

Any idea?

Hi,

I'm unsure if this is an issue, and if it is i'm not sure if it is an issue of the windows runner or gitlab-ci.

In my setup:

• master (today) gitlab-ci-runner-win build with VS2012 on Windows 7 x64
• GitLab CI 4.3.0.pre f1f3353

It appears that the output is not cleared after/before run of the cmds.

That means I can see the output of commit A in the output of commit B which was build
directly after commit A on the same runner.
(I hope its clear what I mean ^^)

I will check the sources of the runner if I can spot something, but would be cool
if someone can confirm its actually an issue or wanted behavior.

Greetz

From the GitLab CI Project Settings page:

All lines will be concatenated in one file and executed. 
If you change the working directory or the environment in one line - it will affect the next lines too

Since the Windows runner executes each command in a new shell, this guarantee is broken, making complex build scripts rather more difficult to use.

Gitlab CI 5.0+ is said to require the official runner at version 5+.

If necessary, this runner should be upgraded to be compatible with this new version, as the protocol may have seen some changes.

There's a shiny new changelog for the runner, but other things may have changed.

Hi,

Me again... :)

I have a repo with submodules.
By adding "--recursive" to the git clone command those get checked out automatically.
IMHO would make sense to add this in the repo.

Commands should have a timeout.

Official runner does a timeout after 7200sec. (Maybe this will be taken from the Coordinator at a later state, missing API?).

This should also be added here!

Rare thing - but I got a setup where sources tree contains links (junctions) to external libraries. And when Build.DeleteDirectory() is called it steps into junction and attempts to remove content there which is definitely bad thing.

Replacing the whole content of DeleteDirectory with

Directory.Delete(target_dir, true);

fixes the issue. So the question is - are there any reasons to not use the default recursive implementation of Directory.Delete which treats junctions correctly?

Directory link can be created with

mklink /j target source

Hi,

is it possible to add Win32 / Win64 / Linux binary ?

We consider to use and contrivbute to this project, but I can't find a license file.

Calling a command with " in parameters does escape "

e.g. running:
compile.bat "name of solution.sln"

in compile.bat you get 1 parameter:
"name of solution.sln"

The README says:

Just checkout this repository, open the project in visual studio 2013 and compile yourself or use one of our precompiled binaries.

but does not tell us how to get them.