SoW: PiP future compliant

[bicschneider]

What’s the user scenario?

As a user, I would like to use pretested integration (PiP) in my Jenkins Pipeline scripts, so that i can utillize the phlow while taking advantage of pipeline features.

Alt. User scenario:
As a user, I would like to know the outcome of my integration (merge/build failed) in git, so that I do not need to go into jenkins to see the status.

What’s the problem?

PiP is not pipeline compliant. @, can you elaborate on the specifics here?.
The SCM information is not publicly available via the Pipeline architecture. The SCM 'object' does not expose information and cannot be retrieved.

What’s the imagined solution?

Move/extend the integration logic to be Jenkins Git Plugin Extension. This way we are in context of the SCM plugin and by that complies with the SCM stage in Jenkins.

Known possible issues

One issue that is unknown and can indicate that could be problematic in solve this:
Git Publisher does not yet work in Jenkins Pipeline: https://issues.jenkins-ci.org/browse/JENKINS-28335
@MadsNielsen did a PoC on the Pretested Publisher indicating that it could be done:
https://github.com/MadsNielsen/pipelinepublisher

In the overall solution, we want to be able to eg. have a three stage aproach:

stage('PiP integration'){
//In this stage make the merge attempt and 'store the merge' for later use. It can either be pushing the merge to the remote repository or using the stash the outputed workspace and unstash where it is needed.
}
stage ('build'){ 
// Restore the same content from 'PiP integration 
// Make the build/PiP check
}
stage('PiP publish result'){
// Update the remote repository according to the build result
}

What’s the intended design?

TBD

What exactly is the Minimum Viable Product (MVP)?

To make the existing plugin compliant with the pipeline as it is large part of the Jenkins future.

What’s the price (fixed, of course)?

TBD

Original issue:

• Process ( rename branches as the verification is ongoing and in case of failure state the origin of issue in the branch name )
• Pipeline
• Parallel verification (maybe matrix plugin)

[sofusalbertsen]

relates to #18

[drBosse]

Could we KISS this?

Avoid bloated solutions with lots of parameters and just have the two steps

Prepare, w one required parameter which would give a workspace based on the integration branch where the changes are merged
and
FinshUp, merge/push the integration branch and delete the ready branch

Leave it to the user what is needed as a test in between these 2

[sofusalbertsen]

@drBosse So what do you want to remove from the solution? As I see it, this is a 2 step process (but with the ability to make anything in between these).

[sofusalbertsen]

Ping @bicschneider, @lakruzz.
We need to push forward here, please add your thoughts so we can take it out to customers.

[lakruzz]

As @sofusalbertsen mentions this ties closely to #18 which kinda concludes that this is not easily done.

So I believe that we still need to see is the contour of a solution that we believe in, and a rough estimate on how much time it will take us to produce that.

I like the idea og starting with a user story - but I don't like the alternative one, since I can't see how these are even related.

Is Napatech the (potential) paying customer on this? Or who is going to receive this SoW for approval?

[sofusalbertsen]

And relates to #21 as well.
@lakruzz I am having problems seeing why this is not something everyone of our customers that uses PiP wants. Jenkins is going Pipeline full frontal, therefore we should do it as well.
If refactoring our current solution is so massive that it is not an option, then I suggest to make a standalone plugin. The actual code needed for this functionality is not more than 200 lines of code as I can see it.
But yes, NT is right now using pipelines, and I want them to not use a scripted approach to PiP, but a plugin instead.

[lakruzz]

I'm getting mixed signals IS it a 200 line update or IS it practically undoable in the current plugin.

I need a Statement of Work

[buep]

I'm closing this, as we now have SoW out based on discussions from the Code Alliance 6th gathering.
Anything that might be missing after that delivery can be made as additional features.

See #37