Continuous Deployment application - jenkins build problems
170 views
Skip to first unread message
Robert Gründler
Jun 30, 2015, 4:34:02 PM6/30/15
to fab...@googlegroups.com
Hi all,
i'm trying to run the CD application, and after creating a project names 'cheese', there are 4 jenkins builds generated by the seed build. The first one is named 'cheese-ci' and the second one 'cheese-it'.
'cheese-ci' builds fine, but 'cheese_it' fails with :
It looks like the *-it builds rely on a branch being available named ${TAG-PREFIX}/-1.0.13, which imho should be generated by the first build, in a post build step:
https://github.com/fabric8io/default-jenkins-dsl/blob/master/seedBuilds.groovy#L140
However, the first build does not have that step configured. After the build succeeds, nothing is pushed to gogs.
I've created the post-build step manually, which worked, but then i end up in an endless build-loop because when the first job pushes the branch to gogs, the gogs
hook triggers the next *-ci build :)
Has anyone an idea how this is supposed to work?
thanks!
-robert
i'm trying to run the CD application, and after creating a project names 'cheese', there are 4 jenkins builds generated by the seed build. The first one is named 'cheese-ci' and the second one 'cheese-it'.
'cheese-ci' builds fine, but 'cheese_it' fails with :
20:26:28 Fetching upstream changes from http://gogs.vagrant.f8/gogsadmin/cheese.git 20:26:28 > git --version # timeout=10 20:26:28 > git -c core.askpass=true fetch --tags --progress http://gogs.vagrant.f8/gogsadmin/cheese.git +refs/heads/*:refs/remotes/origin/* 20:26:28 > git rev-parse origin/${TAG-PREFIX}-1.0.13^{commit} # timeout=10 20:26:28 > git rev-parse ${TAG-PREFIX}-1.0.13^{commit} # timeout=10 20:26:28 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
It looks like the *-it builds rely on a branch being available named ${TAG-PREFIX}/-1.0.13, which imho should be generated by the first build, in a post build step:
https://github.com/fabric8io/default-jenkins-dsl/blob/master/seedBuilds.groovy#L140
However, the first build does not have that step configured. After the build succeeds, nothing is pushed to gogs.
I've created the post-build step manually, which worked, but then i end up in an endless build-loop because when the first job pushes the branch to gogs, the gogs
hook triggers the next *-ci build :)
Has anyone an idea how this is supposed to work?
thanks!
-robert
James Strachan
Jul 1, 2015, 6:24:44 AM7/1/15
to Robert Gründler, fab...@googlegroups.com
The current Job DSL is still under development I'm afraid. The good news is you can hack it however you wish (and pass in the URL to clone when you create the cdelivery template to boot up Jenkins).
Incidentally Christian Posta and Charles Mouilliard recently did a demo of this at Red Hat Summit and hacked it a little bit for their needs to add Gerrit approval:
we're just in the process of merging those changes back now...
Longer term we'd like to try move to Jenkins Workflow / Jenkins Docker Workflow as its a little easier to grok and hack...
More inline...
On 30 June 2015 at 21:34, Robert Gründler <robert.g...@ecosio.com> wrote:
Hi all,
i'm trying to run the CD application, and after creating a project names 'cheese', there are 4 jenkins builds generated by the seed build. The first one is named 'cheese-ci' and the second one 'cheese-it'.
'cheese-ci' builds fine, but 'cheese_it' fails with :20:26:28 Fetching upstream changes from http://gogs.vagrant.f8/gogsadmin/cheese.git 20:26:28 > git --version # timeout=10 20:26:28 > git -c core.askpass=true fetch --tags --progress http://gogs.vagrant.f8/gogsadmin/cheese.git +refs/heads/*:refs/remotes/origin/* 20:26:28 > git rev-parse origin/${TAG-PREFIX}-1.0.13^{commit} # timeout=10 20:26:28 > git rev-parse ${TAG-PREFIX}-1.0.13^{commit} # timeout=10 20:26:28 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
It looks like the *-it builds rely on a branch being available named ${TAG-PREFIX}/-1.0.13, which imho should be generated by the first build, in a post build step:
Good catch.
It looks like Gary spotted this recently...
Its not the "Build" versus "Perform Maven Release" button in the Jenkins UI is it? I agree though it should just work though!
https://github.com/fabric8io/default-jenkins-dsl/blob/master/seedBuilds.groovy#L140
However, the first build does not have that step configured. After the build succeeds, nothing is pushed to gogs.
I've created the post-build step manually, which worked, but then i end up in an endless build-loop because when the first job pushes the branch to gogs, the gogs
hook triggers the next *-ci build :)
Yeah :)
Has anyone an idea how this is supposed to work?
Christian's fork is a little better; but am sure we can improve things a lot more.
There's a general issue with canary releases; you want to make them for each commit; then tag and create new images and artefacts; but you only want to push git tags, docker images & maven artefacts when the canary release is approved (via integration tests + soak tests + acceptance tests + maybe human approval) otherwise there's too much noise upstream etc.
Right now we didn't want to push to avoid the infinite loop. I guess a way to fix the infinite loop is to check if the disk contents change since the last build or something? Then if you just push tags it doesn't force a new canary release?
We were hoping to have an option to promote the git tags + nexus artefacts + docker images as a final build step.
BTW there's so many ways of doing all this; what we're hoping is we can, as a community, build a library of Jenkins Workflow builds that we can all share and fork/hack across projects
so that folks can choose the default workflow to use for all their projects; then override the kind of workflow they want to use on a per project basis (by listing it in a fabric8.yml file)
e.g.
I'd hope for most maven stuff we can come up with a standard set of workflow scripts which folks can choose between; then just configure the different docker images for tools like maven and then configure the names of the environments they want to use etc.
James
-------
Red Hat
Twitter: @jstrachan
Email: jstr...@redhat.com
Blog: http://macstrac.blogspot.com/
hawtio: http://hawt.io/
-------
Red Hat
Twitter: @jstrachan
Email: jstr...@redhat.com
Blog: http://macstrac.blogspot.com/
hawtio: http://hawt.io/
Christian Posta
Jul 2, 2015, 3:04:23 PM7/2/15
to James Strachan, Robert Gründler, fab...@googlegroups.com
Hey Robert! Thanks for giving this a try; sorry for having it in a broke state, was just in the process of merging the changes I had for this.
Else, inline....
On Wed, Jul 1, 2015 at 3:24 AM, James Strachan <james.s...@gmail.com> wrote:
The current Job DSL is still under development I'm afraid. The good news is you can hack it however you wish (and pass in the URL to clone when you create the cdelivery template to boot up Jenkins).Incidentally Christian Posta and Charles Mouilliard recently did a demo of this at Red Hat Summit and hacked it a little bit for their needs to add Gerrit approval:we're just in the process of merging those changes back now...
Changes have been merged.
Longer term we'd like to try move to Jenkins Workflow / Jenkins Docker Workflow as its a little easier to grok and hack...
+1
More inline...On 30 June 2015 at 21:34, Robert Gründler <robert.g...@ecosio.com> wrote:Hi all,
i'm trying to run the CD application, and after creating a project names 'cheese', there are 4 jenkins builds generated by the seed build. The first one is named 'cheese-ci' and the second one 'cheese-it'.
'cheese-ci' builds fine, but 'cheese_it' fails with :20:26:28 Fetching upstream changes from http://gogs.vagrant.f8/gogsadmin/cheese.git 20:26:28 > git --version # timeout=10 20:26:28 > git -c core.askpass=true fetch --tags --progress http://gogs.vagrant.f8/gogsadmin/cheese.git +refs/heads/*:refs/remotes/origin/* 20:26:28 > git rev-parse origin/${TAG-PREFIX}-1.0.13^{commit} # timeout=10 20:26:28 > git rev-parse ${TAG-PREFIX}-1.0.13^{commit} # timeout=10 20:26:28 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
It looks like the *-it builds rely on a branch being available named ${TAG-PREFIX}/-1.0.13, which imho should be generated by the first build, in a post build step:Good catch.It looks like Gary spotted this recently...Its not the "Build" versus "Perform Maven Release" button in the Jenkins UI is it? I agree though it should just work though!https://github.com/fabric8io/default-jenkins-dsl/blob/master/seedBuilds.groovy#L140
However, the first build does not have that step configured. After the build succeeds, nothing is pushed to gogs.
I've created the post-build step manually, which worked, but then i end up in an endless build-loop because when the first job pushes the branch to gogs, the gogs
hook triggers the next *-ci build :)Yeah :)
I've removed this for now. We can make it a little more configurable when to branch/tag in git. We may also want a more relax webhook that can differentiate commits to master vs new tags..
Has anyone an idea how this is supposed to work?Christian's fork is a little better; but am sure we can improve things a lot more.
Yes we can. Actually the yaml stuff james spiked out (https://github.com/fabric8io/fabric8/pull/4380) and the jenkins workflow/docker plugins should make it easer for users to configure the behavior for their projects
There's a general issue with canary releases; you want to make them for each commit; then tag and create new images and artefacts; but you only want to push git tags, docker images & maven artefacts when the canary release is approved (via integration tests + soak tests + acceptance tests + maybe human approval) otherwise there's too much noise upstream etc.
Right now we didn't want to push to avoid the infinite loop. I guess a way to fix the infinite loop is to check if the disk contents change since the last build or something? Then if you just push tags it doesn't force a new canary release?We were hoping to have an option to promote the git tags + nexus artefacts + docker images as a final build step.BTW there's so many ways of doing all this;
That's true. Some people want to treat every CI success as a possible release candidate and tag/version the build up front. That way if a build gets to the end of the gate where it could be released (as a canary, full release, whatever) then you already have everything built/tagged, etc. If it fails anywhere along the path, your delete tags/remove from a staging nexus repo. if it passes, you promote from the staged nexus repo to the release repo and push it out. On the other hand as James correctly points out this method could be noisy (lots of ephemeral artifacts in nexus, lots of ephemeral tags/branches in git, etc). Other groups prefer to version, tag locally, and push along the CD pipeline.. This could end up in QA or PROD before an ops team decides it's time to tag and make it an official "release" even if it's not in production at that point. Then the locally tagged git branch could be pushed up.
At the moment since gogs treats a new tag as a new release i'll remove the branching stuff and re-hack that into the jenkins/fabric8.yaml approach we'll iterate on next.
what we're hoping is we can, as a community, build a library of Jenkins Workflow builds that we can all share and fork/hack across projects
+1 this will be awesome...
so that folks can choose the default workflow to use for all their projects; then override the kind of workflow they want to use on a per project basis (by listing it in a fabric8.yml file)e.g.I'd hope for most maven stuff we can come up with a standard set of workflow scripts which folks can choose between; then just configure the different docker images for tools like maven and then configure the names of the environments they want to use etc.--James
-------
Red Hat
Twitter: @jstrachan
Email: jstr...@redhat.com
Blog: http://macstrac.blogspot.com/
hawtio: http://hawt.io/
--
You received this message because you are subscribed to the Google Groups "fabric8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabric8+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages