On 12/5/13 6:45 AM, Les Mikesell wrote:
On Thu, Dec 5, 2013 at 6:43 AM, Mandeville, Rob <rmandevi...@litle.com> wrote:
So you have to calculate the file on the master?
You can't propagate environment variables to slave except when they start. However, you
can write a properties file on the master (probably in a well-defined location rather
than just "env.properties" as I have said below) and have whatever jobs need
the variables download the file from the master and inject files from it. So on the
master, you would have:
rm -f env.properties
touch env.properties
echo "BRANCH = `some_command_that_calculates_branch` >> env.properties
echo TIMESTAMP = `date` >> env.properties
mv -f env.properties /usr/local/well-known-location/env.properties
Doing it this way (rather than writing to
/usr/local/well-known-location/env.properties directly) guarantees that
/usr/local/well-known-location/env.properties is a complete file at any time.
Doesn't that invite a race condition if multiple jobs run
concurrently? (Assuming they need different values...),
My jobs would all need separate values. In fact only one job
needs any value right now.
But let me try to explain in more detail. I have a job with a
main svn repo, several svn repos that are brought in as svn
externals and one that is a git checkout. These must all be
brought together for a build.
main_repo (svn)
svn_repo1 svn_repo2 git_repo
At SCM upate, main_repo is updated, and this automatically
updates svn_repo1 and svn_repo2, as they are svn externals. On
the master each of those has an svn revision number. Then,
Jenkins seems smart enough that when it goes to the slaves, it
updates main_repo, svn_repo1, and svn_repo2 to the revision it
found on the master.
However, git_repo is not updated on the master, as it is not
(cannot be) an svn external. The (poor) solution now is to have
our build script start with updating the git_repo (cd git_repo;
git pull). But this could potentially have git_repo on the
separate slaves in different states, if someone commits before
one slave is updated and after another.
The solution I was thinking of was to run a script on the master
*after update* and *in the workspace*, just like you mention above
rm -f env.properties
touch env.properties
cd git_repo
git pull
echo GR_BRANCH = `git branch | grep '^\*' | sed -e 's/^. *//'` >>
../env.properties
echo GR_REV = `git rev-list HEAD | wc -l | awk '{print $1}'` >>
../env.properties
Then my branches could get that file, set those env vars at the
beginning of the build, and update the git repo to the desired,
consistent state.
So this is my question. How do I get the master to run the above
script in the workspace, after SCM update on the master?
Thanks....John Cary
--
You received this message because you are subscribed to the Google Groups "Jenkins
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
