Mathias Klette [Tue, 4 Jun 2013 10:01:42 +0000 (12:01 +0200)]
debian_build: use Jenkins parameter BUILD_TRIGGERS instead of commit message parsing
commit message is still parsed for those triggers, but this happens through
call_jenkins instead. this way jobs can use triggers no matter if recent commit
message contains the requested trigger.
Mathias Klette [Thu, 30 May 2013 12:33:49 +0000 (14:33 +0200)]
debian_build: new fixes for new branching model, fix rebasing
also pushing the rebased/merged branch should only be done if all tests have
passed! hence, we shouldn't push the merged branch already in debian_build.
instead, we will try to find solutions to make jenkins push the branch using
post-build actions
Mathias Klette [Wed, 29 May 2013 12:11:23 +0000 (14:11 +0200)]
common_code: reset GIT_BRANCH if it differs from GIT_BRANCH_NAME
Most jobs use GIT_BRANCH_NAME parameter to let user choose the branch to build
the package from while GIT_BRANCH contains the sha commit id of HEAD of most
recent commit (unconfirmed yet).
Mathias Klette [Tue, 28 May 2013 09:48:49 +0000 (11:48 +0200)]
debian_build: fix variable usage and usage of check_call-method
we shall stay with DISTRIBUTION envionment variable yet: let's force the user to
provide the necessary distribution in Jenkins GUI or in call_jenkins.
in the next step we try to remove this parameter from jenkins and base the
decision of what distribution to use on what we find in the changelog. question
to be answered for this:
stable -> squeeze?
our old values like 'production', pau, ppu, ... -> ??
wheezy -> wheezy?
the check_call() method from subprocess seems to return the exit code of command
ran as int. this doesn't behave well in current if-syntax, so we changed it to
match for success code "0" explicitely.
Mathias Klette [Wed, 22 May 2013 16:00:27 +0000 (18:00 +0200)]
do not tag 'integration'-builds!
I missed the point in the requirement: tags should only be created upon a
complete successfull build. this means, that also all tests must complete
successfully in order to create a new tag.
as jenkins is taking care of evaluating test results we can't create the tag in
debian_build beforehand. we'll use git publisher plugin now, to only tag
'stable_$BUILD_NUMBER' if build succeeds!
Mathias Klette [Wed, 22 May 2013 09:13:48 +0000 (11:13 +0200)]
use a real git.Repo().commit() object
as preparation for vdc-bundles-integration scheme:
requirements define to evaluate commit message for different triggers:
* [merge]: integrate all commits of currently committing branch into
'integration'-branch by using 'rebase'
* [no-test]: package build should not run any tests
according to documentation, http://goo.gl/kS1rB,
* [no-test] will be ignored if [merge] is also given in the commit message
* [no-test] will be ignored for 'integration' branch at all - it must run the
full set of tests!
Mathias Klette [Wed, 8 May 2013 17:31:31 +0000 (19:31 +0200)]
liveboot_rsync: don't use archive option for rsync
liveboot_rsync facilitates rsync module whileas dcmanager uses
a dedicated user to sync files via SSH. this causes rsync daemon
on mgmt1 to reset permissions in such a way that dcmanager isn't
capable of resetting the mtime value of "." (parent directory of
destination) and hence throws error in UI. dcmanager doesn't use
the same rsync options (yet), which could make sense to have both
sources operating the same way.
Mathias Klette [Thu, 2 May 2013 17:00:52 +0000 (19:00 +0200)]
common_code, debian_build: cleanup #5
- added CWD to default ENV
- remove unused variables
- facilitate git submodule more
- change the way of tag handling
- beautifying some parts of the code
Mathias Klette [Thu, 2 May 2013 08:38:14 +0000 (10:38 +0200)]
remove CWD variable from common_code
- which used jenkins provided environment variable 'WORKSPACE'
- this in turns leads to errors in debian_repos2db.sh when no such variable exists
- replaced all occurences of CWD in debian_build with it's corresponding ENV['WORKSPACE'] variable