Merge pull request #219 from MosesMendoza/maint/master/promotion_fixes

Signing changes for promotion workflow
(RE-384) Tie downstream jobs to downstream label

Currently the downstream job is executed on any slave. This presents a problem,
since the downstream job calls curl, which isn't available on every platform by
default (I'm looking at you solaris 10). This commit updates the downstream job
template to assign the job to only nodes with the label 'downstream', which has
already been set up on the jenkins server and assigned to various sane linux
hosts.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Allow rerun of repo creation job

You can't currently 're-run' the packaging or repo creation jobs that the
uber_build dynamically generates via 'rebuild last' or 'matrix reloaded'. For
the packaging job this is because of the way we upload files as triggers, and
that's fairly difficult to address - on a packaging failure, the best option is
just to run the uber_build again, or a job that targets the specific failed
cell, e.g. rake pl:jenkins:deb. However, the downstream repo job can't be
re-run simply because the script isn't idempotent - once run, the files it
leaves behind cause a failure if run again. This commit just updates the script
to remove the directory the job creates before starting, if it exists. This way
at least the repo-jobs can be retriggered.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Merge pull request #221 from MosesMendoza/maint/master/allow_rerun_of_repo

Allow rerun of repo creation job
Merge pull request #220 from MosesMendoza/RE-384/master/downstream

(RE-384) Tie downstream jobs to downstream label
Always trigger repo job

This is the first in a series of commits that will set up a callback system
within the jenkins on-demand job creation workflow. Currently, we only trigger
repo creation of packaging succeeds, and only trigger downstream (if passed) if
rpeo succeeds. The downside is, for external pipelines, there is no visibility
into the status of packaging - it just stops, and no notification is recieved
of failure. To remedy this, we will be modifying the workflow as follows:

Whereas before the repo job only triggered if packaging succeeded, now the repo
job will _always_ trigger, but repo creation will only happen if the upstream
(packaging) job succeeded.

Whereas before, if passed in, the downstream job only triggered if repo
creation succeeded, now the downstream job will always trigger. However, the
downstream will be augmented with a parameter, "PACKAGE_BUILD_STATUS", which
will be a string, either "success" or "failure" which will be defined by the
success or failure of the upstream (repo) job. In this way, we can notify the
downstream job (presumably acceptance) of the status of packaging, ensuring
success is only passed if packaging and repo creation both succeed.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Only build repos if upstream succeeded

This commit updates the repo composition job to query whether the upstream
packaging job succeeded or failed. Composition only occurrs if the packaging
succeeded. If packaging failed, this job fails also, so that the downstream job
can know about it. In this way the downstream job can query the status of this
repo job, and if it is successful know that the packaging job was successful
also.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Always trigger downstream job if passed

This commit updates the repo job to always trigger the downstream job (if one
has been specified), even if the repo job has failed. This way the downstream
job can trigger and notify of success/failure of packaging.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Move set -e in repo job to after success determination so we don't fail when we don't want to
Check for and and pass success status in downstream

This commit updates the downstream job to check for the success of the repo job
(which will have failed if either package build or repo creation have failed).
Depending on the result, the downstream job exports
PACKAGE_BUILD_STATUS="success" or "failure." This variable will then be
appended as a parameter to whatever was supplied as the downstream url, so that
the job can be notified. We switch to using --fail on curl so we get a good
exit code.

In order to accomplish adding the parameter to downstream, we add a new utility
method, add_param_to_uri, which adds the given string as a param key,value pair
to the uri. If we were sane we'd use the ruby built-in URI.encode_www_form, but
because we're not, because that will http encode it, which isn't what we want
since we're require the encoding provided by escapeHTML of CGI, since this is
being transfered in the xml of a jenkins job via curl and DEAR JEEBUS WHAT HAVE
WE DONE.
Update README.md for callback
Merge pull request #222 from MosesMendoza/RE-392/master/callback_success

Re 392/master/callback success
make pl:ship make things immutable
Merge pull request #223 from shrug/re-448

make pl:ship make things immutable
(maint) Update file mapping to reference yum_repo_path

Previously the file mapping here used /opt/repository/yum hardcoded, when that
path is available in the @build object as yum_repo_path. This commit updates
the section to use the variable.
(maint) Remove duplicate logic from ship_rpms task

The ship_rpms task previously did the same actions twice, once for el and once
for fedora, using the same 5 lines of code. This commit moves those 5 lines
into a loop over el and fedora so that the code is reused.
(maint) The file mapping needs a trailing slash after dist so that we don't remove the trailing slash from the original pathing.
Achievement unlocked: nitpicking over extra space
Merge pull request #224 from haus/maint/master/ship_fixups

Simple improvements to the ship task
(RE-520) Log mock errors to console

Currently when a package build fails, the mock error is locked away in a temp
dir on an arbitrary rpm build host. This makes tracking down build failures
very tedious and manual. This commit rescues any exceptions when running mock,
and then prints the build or root log (root log if build is empty), to stderr.
This will make the errors immediately obvious in the jenkins job, so that
manual intervention to retrieve build errors will be unnecessary.