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.
Related
I have windows apps with XML text files that I edit on windows and check into GitHub. The files have correct Windows EOL formatting on my dev machine. Then I feed it through a Concourse CI pipeline using the Git resource and a windows worker to build an MSI. When I install the MSI on a Windows machine the XML text files have Linux EOL formatting.
What is the best way to fix this? If I understand Concourse correctly the Git resource is a docker container running on Linux so I can see why the files would get checked with Unix EOL formatting but I don't understand why it doesn't get converted to Windows formatting when the container is made available to the windows task.
Update: Slightly more complicated I have some steps that run on the Linux worker so the files need to have Linux EOL formatting when being used on the Linux worker. Example... pull a repos and pass it off to a job running on Linux to do a bunch of npm | grunt | bower type stuff then shuttle the files over to a Windows worker to build some ASP.NET Web API projects and use the Linux output as the Web UI and package it all up into an MSI.
One better way to ensure eol keep consistent is to manage them through .gitattributes core.eol rules
That will avoid the effect of global configurations (applying to all repos) like
git config core.autocrlf
If true, that global rule (possibly active on ConcourseCI) would change eol automatically.
But a .gitattribute can be added to your repo, and will have precedence. That will ensure consistency.
First, I'm a Jenkins neophyte. I have made a free-style software project in Jenkins to perform my Linux build. The Jenkins server is running on Windows so there are slave nodes configured for doing this Linux build. The sources are kept in a TFS server.
I updated our TFS plugin to the latest of 4.0.0. This plugin says that it is no longer necessary for slave nodes to have the Team Explorer Everywhere package installed as it uses the Java API. However, when I kick off my build, I get this:
Started by user Andy Falanga (afalanga)
[EnvInject] - Loading node environment variables.
Building remotely on dmdevlnx64-01 (PY27-64 CENTOS6-64 LOG4CPLUS PY26-64) in workspace /home/builder/jenkins/workspace/Linux Autotools Build
Deleting project workspace... done
Querying for remote changeset at '$/Sources/Branches/Andy/AutotoolsMigration' as of 'D2015-10-05T18:26:27Z'...
Query result is: Changeset #4872 by 'WINNTDOM\afalanga' on '2015-09-25T23:36:24Z'.
Listing workspaces from http://ets-tfs:8080/tfs/SoftwareCollection...
... Long list of workspaces
Workspace Created by Team Build
Getting version 'C4872' to '/home/builder/jenkins/workspace/Linux Autotools Build'...
Finished getting version 'C4872'.
[Linux Autotools Build] $ /bin/bash /tmp/hudson7081873611439714406.sh
Bootstrapping autotools
/tmp/hudson7081873611439714406.sh: line 4: ./bootstrap: No such file or directory
Build step 'Execute shell' marked build as failure
Notifying upstream projects of job completion
Finished: FAILURE
I log into that system and look in the directory /home/builder/jenkins/workspace/Linux Autotools Build and sure enough, there's nothing there. My configuration is pretty simple.
I have discard old builds checked and a simple rotation (this is just me learning how to use it).
I have it set to "Restrict where the build is done" and a label which associates to the 3 slave nodes for doing this build.
All TFS credentials are input and correct.
No build triggers
A simple shell script for Build->Execute Shell which bootstraps the autotools and calls configure and then make.
What am I doing incorrectly?
I found the answer and am posting it here in case someone runs into this. This seems better than simply deleting the question. The TFS plugin doesn't seem to like spaces in the project name. The name before Linux Autotools Build which didn't work and the name now, LinuxAutotoolsBuild which does.
The errors provided by the Jenkins system didn't provide enough information for this to be apparent. After trying a few other things the thought occurred, "Perhaps the spaces are causing grief."
Hope this helps someone.
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.
So I work with a Linux VM, I have several repos there with code that I run on the VM. I have a Samba share setup on the VM so I can access the repos from a Windows machine and edit them in Windows. There are many reasons why I have this setup but that would be beyond the scope of this question.
The editing experience is rather good but there is one thing left that's an annoyance: I use Atom on Windows to edit my files and it is great at handling changes within a file using git diff internally. However it colors a number of files as having changed when they have not.
To troubleshoot, I opened a command line on the Windows box and ran git status on the repo, it incorrectly showed a ton of files changed when there are actually no uncommitted changes in the repo. I do all of my git operations on the Linux box but it would be nice to at least have consistent status.
Is there some kind of git config on either the Linux or Windows side that I could use to make the two a little more compatible?
Ok, after digging some more, I've found the issue was due to different file mode flags because of my Samba configuration. I was able to fix things by disabling the fileMode option at the repo level:
git config --unset core.fileMode
And setting it globally on the Windows box:
git config --global core.fileMode true
I use jenkins to do auto deployment weekly to a tomcat server, and it is fairly simple to do using the "curl" with the tomcat manager. and since i am only uploading a .war file, so its very straight forward.
But when comes to a backend console application, Anyone has any idea how to use jenkins to upload an entire "set of folders with files" onto a linux box? The project that i have is built via ant and has all the folder inside the SVN.
A couple things come to mind.
Probably the most straightforward thing to do is use the ant scp task to push the directory / directories up to the server. You'll need the jsch jar on your Ant classpath to make it work, but that's not too bad to deal with. See the Ant docs for the scp task here. If you want to keep your main build script clean, just make another build script that Jenkins can run named 'deploy.xml' or similar. This has the added benefit that you can use it from places other than Jenkins.
Another idea is to check them out directly on the server from SVN. Again, ant can probably help you with this if you use the sshexec task, and run the subversion task inside of that. SSHexec docs here
Finally, Jenkins has a "Publish Over SSH" plugin you might try out. I've not used it personally, but it looks promising! Right over here!