We use a official Windows runner from Gitlab-ci. We want to upload artifacts.
We use the 'artifact' keyword in our yaml file to define the artefacts that need to be uploaded. When we commit this is the message we are getting:
gitlab-ci-multi-runner 0.7.2 (998cf5d)
WARNING: artifacts is not supported by selected executor and shell
Using Shell executor...
So is this because it is using a Windows machine? What is the deal here?
Uploading artifacts from the windows shells cmd and powershell are currently not supported. After a while of digging the source I found that according to gitlab-ci-multi-runner\shells\bash.go bash does support it.
The working solution for me is:
install Bash (already included with Git-SCM)
add the bash directory (C:\Program Files (x86)\Git\bin) to your PATH
make sure bash starts if you type bash in the cmd
find your config.toml and modify/add:
executor = "shell"
shell = "bash"
restart your git-runner service
make sure your build scripts are in bash-syntax
(for example run windows commands from bash with cmd.exe /c "dir")
Related
Context
I want to run a bash script during the building stage of my CI.
So far, MacOS building works fine and Unix is in progress but I cannot execute the scripts in my Windows building stage.
Runner
We run a local gitlab runner on Windows 10 home where WSL is configured, Bash for Windows installed and working :
Bash executing in Windows powershell
Gitlab CI
Here is a small example that highlights the issue.
gitlab-ci.yml
stages:
- test
- build
build-test-win:
stage: build
tags:
- runner-qt-windows
script:
- ./test.sh
test.sh
#!/bin/bash
echo "test OK"
Job
Running with gitlab-runner 13.4.1 (e95f89a0)
on runner qt on windows 8KwtBu6r
Resolving secrets 00:00
Preparing the "shell" executor 00:00
Using Shell executor...
Preparing environment 00:01
Running on DESKTOP-5LUC498...
Getting source from Git repository
Fetching changes with git depth set to 50...
Reinitialized existing Git repository in C:/Gitlab-Ci/builds/8KwtBu6r/0/<company>/projects/player-desktop/.git/
Checking out f8de4545 as 70-pld-demo-player-ecran-player...
Removing .qmake.stash
Removing Makefile
Removing app/
Removing business/
Removing <company>player/
git-lfs/2.11.0 (GitHub; windows amd64; go 1.14.2; git 48b28d97)
Skipping Git submodules setup
Executing "step_script" stage of the job script 00:02
$ ./test.sh
Cleaning up file based variables 00:01
Job succeeded
Issue
As you can see, the echo message "test OK" is not visible in the job output.
Nothing seems to be executed but no error is shown and running the script on the Windows device directly works fine.
In case you are wondering, this is a Qt application built via qmake, make and deployed using windeployqt in a bash script (where the issue is).
Any tips or help would be appreciated.
edit : Deploy script contains ~30 lines which would make the gitlab-ci yaml file hard to read if the commands are put directly in the yaml instead of an external shell executed during the CI.
Executing the script from the Windows env
It may be due to gitlab opened a new window to execute bash so stdout not captured.
You can try use file system based methods to check the execution results, such as echo to files. The artifact can be specified with wildcard for example **/*.zip.
I also tested on my windows machine. First if i run ./test.sh in powershell, it will prompt dialog to let me select which program to execute. the default is git bash. That means on your machine you may have configured one executable (you'd better find it out)
I also tried in powershell:
bash -c "mnt/c/test.sh"
and it gives me test OK as expected, without new window.
So I suggest you try bash -c "some/path/test.sh" on your gitlab.
I'm using a gradle plugin written in Kotlin which seems to toggle between flawless victory and disastrous failure and I can't find out why.
Code snippet:
project.exec {
val command = "aws ssm get-parameter --name /config/testconfig/secrets --with-decryption"
commandLine(command.split(" "))
standardOutput = FileOutputStream(secretsJson)
}
This does work from time to time and downloads the Systems Manager properties to a JSON file and all of a sudden doesn't anymore. It's unable to resolve the path to aws, even though /usr/local/bin is in the PATH. The binary is found in /usr/local/Cellar/awscli/1.16.250/libexec/bin/aws though and linked in /usr/local/bin. If called directly the command can be executed without issues.
I've checked the environment variables of both my terminal and my local gradle wrapper and PATH is exactly the same in both.
My colleague is able to run both on his machine (both on macOS).
Any ideas? I'm ... exhausted.
I've checked the environment variables of both my terminal and my local gradle wrapper and PATH is exactly the same in both.
project.exec will spawn another process, with it's own shell and environment. And that process may not inherit the PATH in a way you expect it. You can check that by printing out the environment from inside that process (commandLine("printenv")). Make sure that AWS CLI is still on the PATH.
I am running a Jenkins slave on a restricted environment. This environment will only allow me to execute files in a specific directory.
The problem I have is running simple batch commands.
The slave's java.io.tmpdir being AppData/Local/Temp, jenkins will copy my command in a temp bat file and attempt to run it, like such:
cmd /c call D:\Users\TastyWithPasta\AppData\Local\Temp\hudson8090039221524722157.bat
Here the issue becomes obvious, the command cannot be run due to restriction and the build fails.
Anybody working in a restricted environment and facing the same issues? What would be a good workaround?
Unfortunately, -Djava.io.tmpdir=newpath is not an option since this taps into the Java installation. Maybe there is a way to override it locally?
I'm trying to use bash as the shell on Windows for a GitLab CI Runner.
concurrent = 1
check_interval = 0
[[runners]]
name = "DESKTOP-RQTQ13S"
url = "https://example.org/ci"
token = "fooooooooooooooooooobaaaaaaaar"
executor = "shell"
shell = "bash"
[runners.cache]
Unfortunately I can not find an option to specify the actual shell program that the CI Runner should use. By default, it just tries to run bash which it can not find. I don't know why, because when I open up a Windows command line and enter bash it works.
Running with gitlab-ci-multi-runner 1.9.4 (8ce22bd)
Using Shell executor...
ERROR: Build failed (system failure): Failed to start process: exec: "bash": executable file not found in %PATH%
I tried adding a file bash.cmd to my user directory containing
#"C:\Program Files\Git\usr\bin\bash.exe" -l
That gives me this strange error:
Running with gitlab-ci-multi-runner 1.9.4 (8ce22bd)
Using Shell executor...
Running on DESKTOP-RQTQ13S...
/usr/bin/bash: line 43: /c/Users/niklas/C:/Users/niklas/builds/aeb38de4/0/niklas/ci-test.tmp/GIT_SSL_CAINFO: No such file or directory
ERROR: Build failed: exit status 1
Is there a way to properly configure this?
There are two issues going on here, and both can probably be solved.
gitlab-runner cannot find bash
gitlab-runner doesn't combine unix-style and Windows-style paths very well.
You have essentially succeeded in solving the first one by creating the bash.cmd file. But if you're curious about why it didn't work without it, my guess is that bash runs in your command prompt because the directory that contains it (e.g. in your case "C:\Program Files\Git\usr\bin") is included in the PATH environment variable for your user account. But perhaps you are running the gitlab-runner in the system account, which might not have the same PATH.
So the first thing to do is just check your system's PATH variable and add the bin directory if necessary (i.e. using the System applet in the Control Panel as described here or here). Just make sure you restart your machine after you make the change, because the change isn't applied until after you restart. That should make bash work, even when called from a service running in the system or admin account.
As for the strange error you got after creating bash.cmd, that was due to the second issue. Paths are often really hard to get right when combining bash and Windows. Gitlab-runner is probably trying to determine whether the build path is relative or absolute, and ends up prepending the windows path with what it thinks is the working directory ($PWD). This looks like a bug, but gitlab still has not fixed it (as of version 9.0 of the runner!!) and probably never will. Maybe they have decided it is not a bug or that it is due to bugs in underlying software or tools that they can't fix or that it would be too difficult to fix. Anyway, I've discovered a work-around. You can specify the base path for builds in the config.toml file. If you use a unix-style path, it fixes the problem.
On windows, config.toml is usually in the same folder as your gitlab-runner.exe (or gitlab-multi-runner-amd64.exe etc). Open that file in your favorite text editor. Then find the [[runners]] section and add two lines similar to the following.
builds_dir="/c/gitlab-runner/builds/"
cache_dir="/c/gitlab-runner/cache/"
The path you use should be the "bash version" of whatever directory you want gitlab-runner to use for storing builds etc. Importantly if you are using cygwin, you would use a path similar to /cygdrive/c/... instead of just /c/... (which is appropriate for msys-git or standalone MSYS2 etc).
Here's an example of a config.toml file:
[[runners]]
name = "windows"
url = "https://your.server.name"
token = "YOUR_SECRET_TOKEN"
executor = "shell"
shell = "bash"
builds_dir="/c/gitlab-runner/builds/"
cache_dir="/c/gitlab-runner/cache/"
It looks like you're attempting to link gitlab-ci up with the Windows Subsystem for Linux (which can be accessed by typing bash at the Windows command prompt)? I doubt that this is supported directly by Gitlab's runner configuration.
Instead, I would suggest using Powershell with your shell executor.
Executor = 'shell'
Shell = 'powershell'
You can then drop down into Bash in the scripts you call from .gitlab-ci.yml.
Given that it's bad practice to execute more than very trivial shell scripts within the .gitlab-ci.yml itself (as opposed to calling out to an external script), you lose little by being forced to use a native Windows shell.
I predominantly work on windows OS and quite new to MAC systems. I am trying to set up Jenkins CI tool on one of the MAC machines, I have installed jenkins on mac and it is running on 8080 port.
Issue: I am getting the following error on Jenkins console output when i execute the job:
**/var/folders/zz/zzzivhrRnAmviuee+++++E++++2/-Tmp-/hudson6910375920437308281.sh: line 13:
**ampts: command not found**
Build step 'Execute shell' marked build as failure**
Things I tried:
I added the correct path in .bash_profile and since then I am able to successfully run the ampts command from terminal and every thing works fine from terminal. But the same does not run from the execute shell in Jenkins which is running on MAC.
Earlier the job was running as anonymous I created the account in jenkins and placed .bash_profile with the correct path under ~jenkins/users/home/my.account and restarted jenkins but still I am facing the same issue.
I also tried placing .bashrc under ~jenkins and also under ~jenkins/users/home/my.account but still no success.
Can some one point out what I am missing. or what needs to be done in case of Jenkins running on MAC.
This will depend on how you've started the Jenkins client. If you start it from the command line with the javaws command then I think this will inherit the environment variables of the terminal prompt. If you start the JNLP agent from the browser then it will inherit the system environment (which is different to the bash environment). There's a few things you could try:
Set the PATH variable explicitly in the ~/.MacOSX/environment.plist file (see the Apple docs)
If you are using Ant to run the jobs then you can add the environment variable to the ~/.antrc file (same syntax as the .bash_profile)
Set the environment variable in the Jenkins configure page for this node.