I'm building a group of projects from the SVN. There is a possibility of changing the SVN location time to time. As there are bunch of projects I hope to give the repository url with a environment variable so i can change all the url's easily. Any idea how to do that??
In Subversion Source Code Management, you can use variable in the Repository URL, simply type:
http://my.svn.com/path/to/${VARIABLE}
${VARIABLE} is a job parameters that is defined earlier. Never heard of anyone wanting to use actual environment variables for this, but you can try with the same syntax.
By default, it will give you a red warning that this is not a valid URL. You can disable this warning by going to Manage Jenkins -> Configure System and look for Validate repository URLs up to the first variable name. Put a checkmark there and save.
Related
Since I have the same static rarely changed parameters used by several jobs I decided to put it somewhere in one place of my Jenkins and use it across jobs.
The first thought that came to my mind was to move my 'static data' to the environment variables and get it using Active choice reactive parameter plugin which allows running simple groovy scripts on the job parameters page.
Please note that I know how to get environment parameters in the pipeline, but I do really need to have this data on the build with parameters screen, e.g. once I clicked build with parameters - I need my groovy code inside Active choice reactive parameter was able to read this environment variable and display as a parameter to the user.
A simple example of this need:
The environment variable contains the list of servers, the job is going to perform deployment of the application to the selected server. In this case, I want to be able to write something like this in the groovy script section of Active choice reactive parameter:
return[${env.SERVERS_LIST}]
Unfortunately the example above doesn't work. I wasn't able to find any working solution for this yet.
Well, after a few more tries I finally found a solution.
Instead of trying to read the environment variable in the pipeline manner the simple
return [SERVERS_LIST]
works perfect
I am trying to figure out if there is a difference between the two pre-defined variables in TFS Online 2017: $(Build.Repository.LocalPath) and $(Build.SourcesDirectory). I have a build that uses these two variables and didn't know if I could use them interchangeably or not.
Looking at Microsoft's documentation the descriptions are as follows:
$(Build.SourcesDirectory): The local path on the agent where your source code files are downloaded. For example: c:\agent_work\1\s
By default, new build definitions update only the changed files. You can modify how files are downloaded on the Repository tab.
$(Build.Repository.LocalPath): The local path on the agent where your source code files are downloaded. For example: c:\agent_work\1\s
By default, new build definitions update only the changed files. You can modify how files are downloaded on the Repository tab.
Are these representing the same thing or am I missing something?
They're synonyms. Most standard templates and tasks use the $(Build.SourcesDirectory), so that is what I tend to use.
They often result in the same but not necessarily. As described in the docs:
If you check out multiple repositories, the behavior is as follows (and might differ from the value of the Build.SourcesDirectory variable):
The description for Build.SourcesDirectory on the same page contains a similar note.
Basically if you want to define a custom path for the self checkout and still not need to specify the extra dir, you specifically need Build.Repository.LocalPath.
For clarity, you can still use Build.SourcesDirectory to resolve to the full path if you have the usual
- checkout: self
path: s
and I'd recommend using it whenever possible if so. If you have something like
- checkout: self
path: main_project
then you'd need $(Agent.BuildDirectory)/main_project to reach the same.
I'm constructing some build scripts using FAKE for a TeamCity setup. Part of my build requires me to access the teamcity.build.branch parameter, however because it's not an environment variable, I'm not sure how to access it.
I've tried adding %teamcity.build.branch% to an environment variable in TeamCity but it doesn't seem to like that. I also can't access it using the FAKE git module because team city agents don't use git to get the project files, TeamCity hands it to them.
How would I go about getting the teamcity.build.branch parameter through to my FAKE scripts? Ideally I'd like it as an environment variable so I can pick it up straight from within the script, but I'm open to any other ideas.
Try passing %teamcity.build.branch% as a parameter in your build step.
I figured it out with a bit of help from #Nadeem's answer.
I now have my build.bat/cmd file taking in a parameter which I'm then passing into my Fake.exe call like so:
"packages\FAKE\tools\Fake.exe" build.fsx branch=%1
Then inside my FAKE code I'm using the getBuildParamOrDefault "branch" <default branch here>.
I'm then using this as the branch name. I'm also using a string split on the build param that comes in because normally it's in the format of ref/head/<branch name> and I only want the branch name.
I also had to pass in %teamcity.build.vcs.branch.<project>% instead of %teamcity.build.branch% as my agents didn't like the implicit requirement. I'm not entire sure why this is but all is working well now.
I'm trying to use global variables within Jenkins on Windows to "automagically" retrieve the proper code base from our SCM system, but in each case that I've tried the variable substitution is not happening.
I've set up some global variables, with default values, within "Configure System" and have tried to access them with $VARIABLE, ${VARIABLE} and %VARIABLE% as part of the Branch field for the Surround SCM plugin with no success whatsoever.
I've also installed the Global Variable String Parameter plugin with the same success rate (0%). Using a literal value works just fine, but no type of variable substitution seems to work at all and I'm sure that someone has come upon this before and resolved it.
I've tried searching for something similar to this but nothing really approaches this usage of globals, instead it is normally discussed as a function within an external script, or parameter passed to a batch file, etc.
I've run "set" as the first step and can see that the variable is available, but the substitution is just not happening. If it means I will have to script something, then so be it, as I am trying to make this extremely flexible and as headache free as possible, but that isn't seeming to be the case in this case thus far.
My problem is eerily similar to this post: How are environment variables used in Jenkins with Windows Batch Command?, but again, I'm not looking to script this as it is a MUCH simpler solution to use the variable values directly.
from https://wiki.jenkins-ci.org/display/JENKINS/Surround+SCM+Plugin
Troubleshooting
Please contact Seapine support with questions about the integration or
to report bugs or feature requests.
Set your Jenkins project to be parameterized. Create a string parameter GIT_BRANCH that will be your branch variable (for example).
Under Source Control Management, use your branch variable in the form $GIT_BRANCH
That’s it. When you run your project, you will be prompted to enter a value for your GIT_BRANCH parameter.
I have about 20 jobs using common parameters (user, password), and sometimes the password expires... So I have to change it on all jobs, which is really time consuming (and error prone, I may forget one).
I thought about:
using a kind of magic property file if that exists to have directly lines like KEY, VALUE added into job parameters
adding the same kind of KEY, VALUE pair directly inside build.xml, but where ? And it's really ugly... Maybe with a dedicated XML embedded into the build.xml ?
calling a slave job that would (how ?) push up to the parent one the desired values...
As you can see I'm only starting in Hudson/Jenkins (I'm using Jenkins 1.424.2.2), thanks for your help !
EDIT: I'm not admin of the Jenkins instance, so I cannot have access to global properties...
Go to your Jenkins home and navigate :
Manage Jenkins >
Configure System >
Global properties >
Environment variables > ....
I can think of two approaches:
Use Global properties, found under Manage Jenkins -> Configure system. Here you can define environment variables that should be available to all jobs.
Write a small script that downloads, modifies and posts the job config: http://[jenkinshost]/job/[jobname]/config.xml.
You can read about the api capabilities under http://[jenkinshost]/job/[jobname]/api, here is what it says about reading and changing config.xml:
Fetch/Update config.xml
To programmatically obtain config.xml, hit
[http://[jenkinshost]/job/[jobname]/config.xml]. You can also POST
an updated config.xml to the same URL to programmatically update the
configuration of a job.
I eventually succeeded by:
keeping encrypted credentials in a web page
retrieving them in Hudson thanks to a shell script (wget), decrypt them, and creating a build.properties file in the workspace with lines name=value (in my case ssh.password=...)
This works, because Ant build steps detect this file and pass the variables inside into their context. Thanks to that I could centralize my credentials.