jenkins version 2.249
i am using the jenkins pipeline where i have to source a file on one of my jenkins slave nodes.
I am able to cat the file inside the sh command but using "Source" command getting me an error "source: file.sh: file not found."
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 have a jenkins server that has access to remote k8 cluster. I need to run a shell script as a part of jenkins job and pass it the file that is inside the remote kubernetes pod.
I don't want to copy the file from k8 pod to jenkins server as the file is huge ~25G.
I tried with creating a variable 'kubectl_variable' with value:
kubectl get -f pod:<path to file>
this gives error as:
error: the path "podname:/var/lib/datastorage/dump.txt" cannot be accessed: CreateFile podname:/var/lib/datastorage/dump.txt: The filename, directory name, or volume label syntax is incorrect.
I was thinking of passing this variable to the shell script as:
parse.sh ${kubectl_variable}
I am not sure if I can achieve this or not.
Will appreciate your help.
I got a pipeline called Funcional_Test, I'm trying to run on that pipeline a script located in this path: /home/vagrant/VirtualMachines/software_test.sh
This is te configuration:
When I run the pipeline I got these errors:
Am I missing something? What can I do to fix the issue?
Mention /bin/sh in Command (change it depends on the script type)
Mention the script file in Arguments section in same line
I am having trouble getting Blue Ocean to recognize where my default gradle folder is on my Mac OSX. I have GRADLE_HOME set to /opt/gradle.
I keep getting the following error message when running my shell script ./gradlew assembleDebug:
/Users/me/.jenkins/workspace/project#tmp/durable-d97717dc/script.sh:
line 2: ./gradlew: No such file or directory
script returned exit code 1
I could see two reasons for that error:
Your script is not executed in the folder where your gradlew lays.
The gradlew has not set the correct permissions set for the calling user.
Adding a check for existing and the correct permissions on the file to execute could help you to sort these problems out.
I have few shell commands that needs to be executed when a build is getting ready. In Jenkins, I have created a Freestyle project with execute shell options as:
#!/bin/sh
cd /path to kafka folder
bin/zookeeper-server-start.sh config/zookeeper.properties &
bin/kafka-server-start.sh config/server.properties &
cd /path to elasticsearch
bin/elasticsearch
I am able to execute this shell commands from a local file but not through Jenkins.
Here is the Console output I am seeing in Jenkins:
/Users/Shared/Jenkins/tmp/hudson2342342342342357656.sh: line 2: cd: /path to kafka folder: Not a directory
Build step 'Execute shell' marked build as failure
Finished: FAILURE
Any help on how I can fix this? Thanks.
It is a permission issue. Please check your Jenkins user has enough permission to run this shell commands
The best way to find out what's wrong (e.g. permissions issue; folder doesn't exist; etc), do this:
Log into the slave node that is executing this job (if there is none defined, it's probably the Jenkins server itself ("master")
If on "master": become the user that Jenkins runs as (most likely 'jenkins'): sudo su - jenkins (if you have sudo/root access), or su - jenkins (if you know jenkins's password)
If the job runs on another slave, find out as which user the Jenkins server connects. Become that user on the slave node.
cd /path/to/workspace (you can find the job's workspace by looking at the console of a job run)
Now run your commands from a shell as they are in the build step - it may become more apparent on why they fail.