That comes close to working.  But doesn't allow me to keep using auto
builds based on polling for all branches.

I setup a test build that used COMMIT_TO_BUILD as a parameter and set it
for the "Branches to build".  When I used values like "origin/stable/1.5"
it would correctly set the GIT_BRANCH environment variable and checkout the
correct branch.  So that part works great. :)

There were several things that didn't work though. I set the default value
to "*"  (also tried with "**" and "").

Didn't work:
  1. manually spawn a build to get the latest branch (ie. do what it would
do if I wasn't using the variable but instead was using "**" directly).
 This sets the GIT_BRANCH value to "*" and seems to fail the checkout.

  2. setting up SCM polling to pickup new changes doesn't work.  It never
seems to find that there was a change on a branch that matches.

Do you know any way to get these two items working while still allowing
direct setting of the branch/tag/commit to build?

-Allen


On Fri, Feb 10, 2012 at 5:40 PM, Sami Tikka <[email protected]> wrote:

> Check the Parameterized build. Enter a variable name, like VARIABLE.  Then
> specify the "Branches to build" as a $VARIABLE.
>
> You might want to have the default value of the variable be "master" or "*"
>
> You'll have to figure out how your build process tells a gold build apart
> from a normal build.
>
> I myself don't do that. My build process makes only one kind of artifacts,
> the ones I could give to the customer when they have passed all tests.
>
> -- Sami
>
> Allen Bierbaum <[email protected]> kirjoitti 11.2.2012 kello 0.33:
>
> > We have a build that is working fine with git to monitor and build all
> branches in our repository.
> >
> > - For Branches to build we use the default of: '**'
> > - We skip internal tagging and we don't do any merging operations.
> >
> > To release a version of our product, we tag a git commit on one of our
> stable branches, then we want to build that specific tag to make the build
> to deploy.
> >
> > What we would like to do is setup our normal build to have and
> additional parameter:  GOLD_BUILD_TAG
> >
> > So the steps we would like to do for a release build are:
> >   * Tag a commit using a gold tag. (ex: '2.8.3')
> >   * Load Jenkins and go to our normal build job, queue a manual build
> with the value of GOLD_BUILD_TAG set to 2.8.3
> >   * Have Jenkins checkout the code for that tag and run the normal build
> scripts
> >   * The scripts will notice it is a gold build and do the right thing to
> create a package
> >
> > The problem is we can't figure out how to do the 3rd step and make
> Jenkins git plugin checkout the code for the tag.
> >
> > What are we missing?  Is this possible?  Can we do it using a parameter
> in a "normal" build?
> >
> > -Allen
> >
>

Reply via email to