Mathias Klette [Mon, 24 Jun 2013 11:42:33 +0000 (13:42 +0200)]
debian_buid.py: reset new_tag when build with autoincrement
let's assume this:
- user changes files but not version in changelog and commits
- call_jenkins accepts and triggers build
- debian_build.py figures out version / tag to create from changelog
- debian_build.py will incrase version number and pushes new HEAD back to origin
- call_jenkins will not push trigger another jenkins call
- debian_build.py will build with the new version
- tagging must happen when build was successful BUT with the new version number
instead of the one gathered in the very first beginning of the script
Mathias Klette [Sun, 16 Jun 2013 01:49:01 +0000 (03:49 +0200)]
debian_build: when rebase failed use some more actions to recover
-------- Original-Nachricht --------
Betreff: Jenkins Build dev_vdc-bundle - failed rebase not cleaned up correctly
Datum: Fri, 14 Jun 2013 20:33:44 +0200
Von: Ramona Koch <ramona.koch@profitbricks.com>
Antwort an: ramona.koch@profitbricks.com
An: dcops <dcops@profitbricks.com>, Core <core@profitbricks.com>, Mehrdad Arifi <mehrdad.arifi@profitbricks.com>
Hi DC Ops, Hi Core, Hi Mehrdad
I just noticed, that the 'workspace' is not correctly cleaned up, if the rebase had failed.
All builds trying to merge afterwards will also fail during rebase with:
It seems that I cannot create a rebase-apply directory, and I wonder if you are in the middle of patch application or another
rebase. If that is not the case, please
rm -fr /var/lib/jenkins/jobs/dev_vdc-bundles/workspace/.git/rebase-apply
and run me again. I am stopping in case you still have something valuable there.
@DCOps:
I checked your debian_build.py at:
337 try:
338 src_branch = local_branch # save the original branch
339 dst_branch = 'integration' # define the new branch
340 local_branch = dst_branch # reset env for
git-buildpackage
341 gitrepo.git.rebase('origin/' + dst_branch)
342 gitrepo.git.checkout(dst_branch)
343 gitrepo.git.pull()
344 gitrepo.git.merge(src_branch)
345 logger.info('Rebase and merge from branch "{src_branch}"
completed. Now in "{dst_branch}".'.format(
346 dst_branch=dst_branch,
347 src_branch=src_branch,
348 ))
349 except Exception as error:
350 logger.error('Rebase has failed!', exc_info=error)
351 gitrepo.git.reset('--hard',src_branch)
352 exit_error()
and I assume that 'git reset --hard' is not enough. Probably a 'git rebase --abort' needs to be done before. If this does not work - simply removing the mentioned file will work.
Could you check, if my assumption is correct and fix it, please.
extract_storage: fix apt sources for master and develop
The master build job 'extract-storage-kernel-and-modules' extracts
the wrong sources. It takes the latest develop kernel as the apt
sources for 'production-proposed-updates' are missing.
So add the missing sources before installing the kernel and the
out-of-tree modules.
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.
projects / profitbricks / jenkins-build-scripts.git / log