Does anybody know where I should place my buildkite global hook scripts on a windows agent machine?
I place it in the hooks folder as specified in the buildkite-agent.cfg ... But it does not work.
It works just fine when using an Ubuntu agent!
Hooks support was added to the Windows release in Buildkite Agent version 3, which is currently in beta and available from the GitHub releases page. You need to download the latest beta.
You might also need to add .bat to the end of your hook file name, like ...\hooks\environment.bat.
To export your environment variables make sure you use set:
# ...\hooks\environment.bat
set FOO="bar"
Now in your job batch files or scripts you should be able to use the variable:
echo "%FOO%"
# outputs "bar"
Related
This answer points to the new repo command. The repo command points to the old site in older versions of repo. I have a shared Ubuntu 16 system where I was hesitant to update the repo command. How can point repo to the migrated repo at https://android.googlesource.com?
repo is just a Python script which has the correct url in the version I have on Ubuntu 18. Thus, a simple workaround is to just modify the URL in your script.
The failure is apparently a result of repo looking for its own repository so it can report if your current version is out of date (maybe it is used for other things?). My newer version of repo sets the URL differently:
The script looks for an environment variable named REPO_URL which, if set, overrides the location. If the variable is set, the script just uses it.
If the variable is not set, the script sets REPO_URL = 'https://gerrit.googlesource.com/git-repo'
I have a Jenkins master on Windows which runs some Windows builds.
The git client plugin in configured with a fixed path to git as "C:\Program Files (x86)\git\bin\git.exe"
I've now created a Linux slave, but when I run a job on there, it's trying to run the command "C:\Program Files (x86)\git\bin\git.exe init", and obviously fails.
Is there a simple solution to this? I think I've resolved it already by modifying PATH on the Windows master, and the fixed path to git is now just "git" so would work on both OSs.
Is the "correct" way to resolve this for Jenkins, or is there another/better way to do this?
Thanks.
My problem was slightly different, but my solution also applies for this question here. Jenkins Poll SCM (Git) on Windows master / Build on Linux slave
When using the "Git installations" option, you will need to create different jobs, one with each Git Installation. Modifying the PATH either on windows or linux, sometimes might not be an option (in my case, I only have access to Jenkins web UI).
Instead, just make the Default Git installation to point to whatever the Master git installation is (e.g. c:\apps\git\bin\git.exe), and then configure the custom "Tool Locations" for each node. This way you can run the same jenkins job in different master/slave OS. Steps:
Manage Jenkins > Manage Nodes
For each node having git location other than the one provided in the "Git installation", do:
2.1 Open node configuration page (Configure icon)
2.2 Check "Tool Locations" if not already checked
2.3 Click "Add"
2.4 Select "(Git) Default" on the dropdown
2.5 Enter the path to the slave node git installation (e.g. /usr/local/bin/git)
2.6 Save
Repeat steps 2.1 to 2.5 for each Linux slave the job may run.
Node configuration on linux should look something like this:
I believe the additional "git installations" are more suitable, as #Jayan mentioned, when you need to have multiple git installations or you need to run, for some reason, a specific version of git for select Jenkins jobs.
Ensuring "git" in the path of all slaves and master is one good way.
However Jenkins can have multiple installation of git (true for other tools such as jdk, groovy...)
You can configure this from http://server-url/configure
Click on "Add Git" and provide new git with different name and path
You can then "select which git to use" in the "jobs" configuration.
This approach has a positive side effect. It will allow you to use different git client versions (say for testing)
The same environment variable for git dir is fine for that.
My issue was Linux master/Windows slave but this could be applicable either way.
The additional behavior Force polling using workspace did the trick for me.
I didn't have the necessary permissions to make the changes in the other solutions. There might be other considerations you need to take before using this behavior so check the plugin docs before implementing.
I installed Jenkins in my local machine(Windows) & I have created one new job using Jenkins and it's works perfectly... Now I have installed Jenkins in one dedicated Linux Server... How to migrate the job from windows(local machine) to newly installed Jenkins on Linux server??
The safest solution is to use the Job Import plugin.
Install this plugin on the Linux server, and next import the job from the Windows Jenkins URL :)
You can also check in your Job's configs with some smart .gitignore (or whatever your choice of SCM is) and use the %JENKINS_HOME% as a checked in and versioned directory in the SCM of your choice.
Job config's are OS independent, though the job itself might have OS specific scripts (if you use a shell script instead of a mvn pom file / ant build.xml).
Then you can just check out your checked in job repo to the new linux host's $jenkins_home directory and start up jenkins. all your jobs should be found and added to your linux jenkins (with out the need for a plugin).
Generally speaking... the less plugins, the more stable your Jenkins install will be.
We have an application that runs as a service daemon on a RedHat system.
For now, the RPM we have to install this package creates a soft link from our application's library folder into /usr/lib64, and the daemon recognises that.
I would like to be able to set the LD_LIBRARY_PATH in the init script (/etc/init.d/myscript) so that we don't need to create that soft link (therefore, if multiple applications that use different versions of the library are installed, they will use what is in their own installation folder, and also we won't mess with the standard lib folders).
Is this possible? I tried a simple LD_LIBRARY_PATH=/opt/myapp/lib:/$LD_LIBRARY_PATH but that did not seem to work...
Try next in your init script:
LD_LIBRARY_PATH=/opt/myapp/lib:/$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
I need to update Apache Ant on my server.
I downloaded the newest Ant, built it, and (I thought) installed it. But when when I check it says the old version is still installed.
How do I update/replace the previous version of Apache Ant on a CentOS 5.? server?
take care,
lee
As mentioned it's probably getting picked up in your path. Post the output from echo $PATH
To configure your CentOS after installing a new version of Apache Ant, proceed to the following steps:
Locate the directory where the new Ant is located
Set the ANT_HOME environment variable to this directory
Add $ANT_HOME/bin to your PATH
P.S. To modify environment variables, you may edit the /etc/environment file, and reboot, or modify your local .bashrc. Look at your current environment variables by analyzing the output of printenv, e.g., to see the current value of PATH and then add the Ant path to it, e.g.
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin:/usr/local/ant/bin