Redesign what happens in case an integration or build fails/succeeds

[bicschneider]

when an integration fails (merge):

• delete origin/*/<triggered>'s
• push master to origin/mergefailed/<triggered>
• delete origin/ready/<triggered>

when build fails ( integration went well - build, test etc failed )

• delete origin/*/<triggered>'s
• push master to origin/verificationfailed/<triggered>

when an integration and build succeeds

• push master to origin/master
• delete origin/*/<triggered>

Rational:

• Developers can 'read' from the git repo what happened (reason)
• Developers can see if nothing happened (did not get triggered)
• Developers can get the exact sha1 that was integrated in case of a failed build/test
• DevOps can easily detect that is missing to be integrated in case of Jenkins server downtime
• Colleagues can detect/pickup work from peers in case of failures
• Plugin can cleanup completely when it is finally successfully push to master

[bicschneider]

@JKrag : Thanks for the thoughts and I believe caught the details correctly.. :)

[drBosse]

Is this actually solving any 'real' Problem, understand you can do this, but does this add Value?

[buep]

I'm along the lines with @drBosse, but it seems like @JKrag have some challenges that needs to be solved so I want to know more about the underlying root causes.

I'm a bit reluctant against changes like these, as the hole setup and use of the plugin becomes more complext. Image you would write the documentation of the above... or extend our current state-diagram behind the plugin. It becomes way more complex, so the reasons and value have to be good.

So for the rational examples mentioned above, I'm very interested I why I want to do so.... here is my questions and thoughts...

Developers can 'read' from the git repo what happened (reason)

Why do developers want to read from the git repo what went wrong? Isn't that reported better by the build systems, where the actual failure is shown from the log file? I can't see the real reason from git, just that something went wrong?

Developers can see if nothing happened (did not get triggered)

Should we solve the problem that it doesn't trigger instead? It should always trigger, unless there is a failure and then nothing is reported anyway?

Developers can get the exact sha1 that was integrated in case of a failed build/test

I guess this covers you can download the integration commit origin/verificationfailed and look at it? Is that to avoid that I as a developer have to redo "integration process" to look at that exact commit because it helps me debug?

DevOps can easily detect that is missing to be integrated in case of Jenkins server downtime

This is the same today - everything pushed to ready/*

Colleagues can detect/pickup work from peers in case of failures

How will that be easier with the above solutions? I can see that today as well when build fails?

Plugin can cleanup completely when it is finally successfully push to master

Which situations today can we not clean up completely?

[JKrag]

I think @bicschneider more or less caught my specific suggestions, but might not have succesfully explained the root rationale.

My main point was actually to simplify, not increase complexity, so lets start at the beginning.

The thought arose when going over how to teach the workflow when running pretested, and the "mess" you have to explain for the situations where your delivery failed to integrate and you either have to delete the remote ready/ branch or force-push over it, especially if you try to live in a "single commit per feature" mode and thus used e.g. amend to fix your delivery.

This brought me back to previous discussions where we have concluded that it would actually be much cleaner if the plugin always deleted the ready branch, whether it failed or not. This would have two major advantages:

• The semantics would be clean. A "ready" branch indicates to the build server that there is something to do. When picked up, there should no longer be a ready branch, because there is no longer anything to do!
• We simplify the workflow needed when reworking a change that has failed integration or build, as we can just push to the same ready branch again.

The creation of temporary mergefailed/xyz and buildfailed/xyz branches is mostly a compromise to accomodate those that feel that just deleting the ready branch on failure is to radical. I still imagine that most "debugging" will be done as now using the build log etc.

In the mergefailed scenario the developer already has the local branch and can try the merge locally or rebase, and the server side branch is only needed if somebody needs to take over resolving the merge or for really weird server-side debugging of the actual merge.

In the buildfailed scenario, it might actually be "real world" useful to be able to pull down the merged result and run/debug a local build on the exact failed code. Theoretically, it could also be used to trigger a new build on jenkins that maybe uses a different compiler or setup, or does a full clean build if the normal pretested is set up to use incremental for performance reasons.

To summarize: My main goal is to clean up the semantics around the meaning of "ready" branches.

• They should mean only one thing: "Here Jenkins, please pick me up".
• Listing all ready branches should tell we clearly what has yet to be integrated.
• If I want to re-deliver a feature branch because something failed, I should not have to bother with (or teach as it is) git push origin something:somethingelse" syntax ofgit push --force`

[buep]

Okay, thanks for the elaboration - how far will always deleting the ready branch bring you?

That is actually already a planned feature, but can't find an issue on it (it might be on on of the three other issue trackers we have - migration to github issues not finished).

Cleaning up always I think is a good strategy, and makes it easy to redo integration in case of temporary failures etc.

As I read your suggestion, always deleting the ready branch solves almost any of the challenges.

Could that be an okay solution for now?

[JKrag]

I think that deleting the ready branch would get us a long way in making the storytelling easier. I just thought that this solution had been discarded in its pure form?

Honestly, I can't really even claim that I am using the plugin at any customers, as I haven't done any Jenkins for however long. I only use it very occasionally as an end user within Praqma.

My main motivation for proposing changes are the ongoing discussions about the plugin and my perspective as a trainer that has to explain the workflow.

The current discussion was kicked of last week when I was reviewing @bicschneider's slides for a customer workshop, and it got us thinking about why the workflow ends up being so complicated (seen from a git newbie perspective at least).

[buep]

Please close this issue if you're okay with #25 I wrote about deleting the branch - always.

Since I consider @lakruzz the concept owner of the pretested integration workflow I will like to hear his opinion before we change something.

[lakruzz]

I discussed @bicschneider suggestions with him and @MadsNielsen yesterday. and although I didn't quite got the point from the description above, It made sense when we discussed it and I think we should take it to the next level.

I'd like to focus on the end user experience and if these changes enables us to have a self-cleaning, never failing process, then lets start by describing it (update the documentation in a draft version) and if it truly makes the user experience better (I believe it will) then let's go!

[buep]

@bicschneider or @JKrag - can you please groom this issue then as to what Lars asks for.

[buep]

Grooming mean describe issue for actual work - link to this.

[buep]

Is part of our SoW in #38