Add optional parameters fail-no-reports and fail-invalid-reports that
set the build status to failure if no valgrind reports are available
or if the reports are malformed.
This parameters have been added to the Jenkins Valgrind Plugin
version 0.21.
Change-Id: I558802896f24a596f07957ab58a83fcaf6054093
JJB didn't actually handle unicode data very well for a couple reasons.
First the local yaml loader was loading files into yaml as strings
instead of unicode which we should just go ahead and do because yaml's
built int loader loads utf-8 by default (and we don't override the
default). Second we need to do parameter substitution on unicode and
regular strings so change the substitution typecheck to use basestring
instead of str. Finally we need to use UTF-8 as the encoding when
emitting XML so do that.
Add tests to actually test this in the yamlparser tests. The addition of
these new tests comes with a little bit of cleanup in the test classes
to make sure we load unicode files as utf8 more consistently.
Change-Id: I2169e19aae2cdc7ddbd1e7217ef7584c786a039a
Fixes-bug: 1361090
This feature allows one to specify the user id for the jenkins
ssh-agent-credentials in the wrappers section of the yaml file.
Also providing yaml and corresponding xml files for testing.
Change-Id: I6c19945450c6ef55fead72c32594adb5a9b807c6
The JJB unit tests no longer pass, due to an upgraded version of
tox which sets PYTHONHASHSEED to random values. Since the ordering
problem introduced is a difficult one to smash, this just sets
PYTHONHASHSEED to 0. This also fixes the syntax of the
"[testenv]setenv" configuration setting.
Change-Id: I61fdbdf1a5099bcbacaeba59ff5001bb23df8cfd
Related-Bug: #1348818
I had the use case of a lot of projects sharing the same job template
that uses a lot of variables. That requires each project to define all
the variables even if they are mostly identical.
This patch propose to define varialbes as 'defaults' and have them
applied in the job-template magically (oneline diffs always have that
feeling to me).
So instead of:
- project:
name: project1
arch: amd64
builder: debuild
lintian: true
jobs:
- '{name}-build-{arch}'
And so on ...
I can just:
- defaults:
name: sanebuild
- project:
name: project1
defaults: sanebuild
jobs:
- '{name}-build-{arch}'
And override the arch as needed either in the project or by passing it
to the job.
Without this patch, the provided yamlparser fixture
template_honor_defaults.yaml would raise:
arch parameter missing to format echo Build arch {arch}.
Given: {'': '', 'jobs': ['build-{arch}'], 'name': 'project-name'}
Change-Id: Ida1e27eb47356d9cae42175743bd2fd52eb9d869
Gerrit trigger in addition to project name, branch and
file-path also supports when-to-trigger limitation
based on topic of the change, this adds support for that.
Change-Id: Icfcb3f02903a61294d23dd53308287a67927c777
The docs was a little confusing in that used a single term 'configuration' to
referred to both the JJB global configuration and the job definitions.
This change clarifies that by changing 'configuration' in a few places
to 'job definition' to make it less confusing.
Change-Id: Ie64e7d899b793c9c8e86e51076c020640e336a40
The term 'testing' is overloaded. I thought it meant running the actual
JJB tests instead of running the JJB application. I think a good way to
distinguish the two is to use the term 'test mode' when it's in the
context of running the JJB application with the 'test' parameter.
I've already been using the term 'run in test mode' quite a bit in
my JJB reviews to distiguish it from the actual JJB tests.
Change-Id: I2076189e3ae55caa20d0894fb20859a7c461e46a
The defaults can make use of variables passed by the project and I am
taking advantage of that feature in my templates.
With 70ed2236 / https://review.openstack.org/#/c/85336/ there is a
regression which cause the test to fail although it pass with parent
commit d833015.
Change-Id: I57d023657eec4f6f8f29980100185fcfd7e77b1f
This reverts commit 70ed22362a9c13ea9f3165e5747dcca281ad439c.
I knew I should have tested the patch with my own templates. Doing so I
discovered a nasty regression:
The defaults can make use of variables passed by the project. By moving
applyDEfaults to be called after deep_format is performed on job
templates, any substitutioncontained withing defaults is no longer
correctly replaced by project parameters.
Change-Id: I69ffb3e28093af6db62962786d9275bf3ba4e115
Make sure the example referenced in the documentation for ``Job Groups``
actually makes use of 'job-group'.
Change-Id: Ib78bdb459db23f57093c1fd4a6dd74a5080dc239
