Upcoming JEP for usage of Incrementals repository

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Upcoming JEP for usage of Incrementals repository

Jesse Glick-4
After IEP-9¹ there was a need for an actual system for producing and
consuming these quasi-release “incremental” artifacts from Jenkins
projects (typically based on Maven). This is just a heads-up that I am
working on a preparing a JEP, probably for the 3xx “Essentials”
series; and a reference implementation, namely some Maven tooling.
This is being tracked under JENKINS-50686². Anyone with deep
understanding of Maven (like Stephen…) is encouraged to take a peek at
my ongoing work.

¹ https://github.com/jenkins-infra/iep/blob/master/iep-009/README.adoc
² https://issues.jenkins-ci.org/browse/JENKINS-50686

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2m32MFymBnZX8o7PhuVqFUzzBCGXwYKnLaRN8v_Tud5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming JEP for usage of Incrementals repository

Jesse Glick-4
Filed a draft request:

https://github.com/jenkinsci/jep/pull/84

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2GPoCqEBvr4yKEcKtm59%2BJ_8p4NCPmUN%3Du4Swbus%3DEuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming JEP for usage of Incrementals repository

R. Tyler Croy
(replies inline)

On Fri, 13 Apr 2018, Jesse Glick wrote:

> Filed a draft request:
>
> https://github.com/jenkinsci/jep/pull/84


Jesse this is a very thorough and well-thought out document! Thank you so much
for putting the effort into it.

I understand that you have prototyped this work with strictly plugins at this
point, and the document makes allusions to core and 'modules' potentially being
able to use this same approach and tooling.

The only question I had was whether you think it's important to verify that
core and modules function with this model before rolling out this type of a
design? From the IEP-9 standpoint, I don't really care what tooling is required
to get  incremental builds into the maven repository, but I'm not sure if you
consider applicability to core part of "acceptance criteria" for this design.

I hope the question makes sense, put more shortly: does core need to be figured
out for this to come into effect?




Have a good weekend :D

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20180414002112.GE1836%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming JEP for usage of Incrementals repository

Jesse Glick-4
On Fri, Apr 13, 2018 at 8:21 PM, R. Tyler Croy <[hidden email]> wrote:
> [Do] you think it's important to verify that
> core and modules function with this model before rolling out this type of a
> design?

Yes I would consider that a prerequisite for this JEP to be Accepted
and the system to be rolled out for general use:

https://issues.jenkins-ci.org/browse/JENKINS-50692

I am not sure if there is some convention for indicating in the JEP
itself, or in JIRA, which stories in an Epic like JENKINS-50686 should
be considered “mandatory” vs. “optional” for various stages (Draft,
Accepted, Final).

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3r7VDqUYBQ1PKf4jdiSmGmOYneaqi%3Dy3S-zm3T6%3D9wXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming JEP for usage of Incrementals repository

Baptiste MATHUS
Hello,

Finally took some time to review the JEP 305, thanks a lot again Jesse for that big step forward, here's some feedback:


I guess we should then add also RequireMavenVersion 3.5+ shouldn't we?

* I love the part https://github.com/jenkinsci/jep/blob/master/jep/305/README.adoc#usage-from-the-update-center and the idea that we do GitOps and get better traceability/revertability ("Emergency rollbacks are as simple as git revert." indeed). This is easily controllable manually, and can be automated/supported via additional tooling progressively.


I agree with the global reasoning, small concern about "borked releases". When one is using MRP, a burned release is /just/ running MRP again.
If a given commit does map to a given release naming with JEP-305, then if something goes wrong during "mvn deploy", like say a failure in the middle of the physical upload, then I cannot (rightly) retry to override that borked binary.

In that case, do I have to create some kind of fake commit to retry, or even git commit -m "fake commit to retry release deploy" --allow-empty ?



2018-04-14 13:50 GMT+02:00 Jesse Glick <[hidden email]>:
On Fri, Apr 13, 2018 at 8:21 PM, R. Tyler Croy <[hidden email]> wrote:
> [Do] you think it's important to verify that
> core and modules function with this model before rolling out this type of a
> design?

Yes I would consider that a prerequisite for this JEP to be Accepted
and the system to be rolled out for general use:

https://issues.jenkins-ci.org/browse/JENKINS-50692

I am not sure if there is some convention for indicating in the JEP
itself, or in JIRA, which stories in an Epic like JENKINS-50686 should
be considered “mandatory” vs. “optional” for various stages (Draft,
Accepted, Final).

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3r7VDqUYBQ1PKf4jdiSmGmOYneaqi%3Dy3S-zm3T6%3D9wXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6_3jup2kX6BpKv6znSY_%3DLyjBLBBg6PWJ8-KiM5EzJog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming JEP for usage of Incrementals repository

Baptiste MATHUS


2018-04-19 13:12 GMT+02:00 Baptiste Mathus <[hidden email]>:
Hello,

Finally took some time to review the JEP 305, thanks a lot again Jesse for that big step forward, here's some feedback:


 

I guess we should then add also RequireMavenVersion 3.5+ shouldn't we?

* I love the part https://github.com/jenkinsci/jep/blob/master/jep/305/README.adoc#usage-from-the-update-center and the idea that we do GitOps and get better traceability/revertability ("Emergency rollbacks are as simple as git revert." indeed). This is easily controllable manually, and can be automated/supported via additional tooling progressively.


I agree with the global reasoning, small concern about "borked releases". When one is using MRP, a burned release is /just/ running MRP again.
If a given commit does map to a given release naming with JEP-305, then if something goes wrong during "mvn deploy", like say a failure in the middle of the physical upload, then I cannot (rightly) retry to override that borked binary.

In that case, do I have to create some kind of fake commit to retry, or even git commit -m "fake commit to retry release deploy" --allow-empty ?



2018-04-14 13:50 GMT+02:00 Jesse Glick <[hidden email]>:
On Fri, Apr 13, 2018 at 8:21 PM, R. Tyler Croy <[hidden email]> wrote:
> [Do] you think it's important to verify that
> core and modules function with this model before rolling out this type of a
> design?

Yes I would consider that a prerequisite for this JEP to be Accepted
and the system to be rolled out for general use:

https://issues.jenkins-ci.org/browse/JENKINS-50692

I am not sure if there is some convention for indicating in the JEP
itself, or in JIRA, which stories in an Epic like JENKINS-50686 should
be considered “mandatory” vs. “optional” for various stages (Draft,
Accepted, Final).

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3r7VDqUYBQ1PKf4jdiSmGmOYneaqi%3Dy3S-zm3T6%3D9wXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6RN0wn8-FcHA546TF%3Dj0dmin4U3hyTK77M2RUewJpBWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming JEP for usage of Incrementals repository

Jesse Glick-4
In reply to this post by Baptiste MATHUS
On Thu, Apr 19, 2018 at 7:12 AM, Baptiste Mathus <[hidden email]> wrote:
> When one is using MRP, a burned release is /just/ running MRP again.
> If a given commit does map to a given release naming with JEP-305, then if
> something goes wrong during "mvn deploy", like say a failure in the middle
> of the physical upload, then I cannot (rightly) retry to override that
> borked binary.
>
> In that case, do I have to create some kind of fake commit to retry, or even
> git commit -m "fake commit to retry release deploy" --allow-empty ?

You could I guess, but it should not be necessary because unlike our
current process for MRP, I am working on server-side deployment.
Rather than `mvn deploy` (which is indeed flaky), it is using
Artifactory REST with `X-Explode-Archive-Atomic`¹:

https://github.com/jglick/incrementals-downstream-publisher/blob/e80393721af3fad30ff0c6c7af4a1c56ef1b0ae2/sample-downstream.groovy#L9

¹BTW Google Image Search gets this all wrong.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0nQ5BRnDymSmC%3DsjsRMYYiPrFsh7-8F-vb9UpbzQ2R%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.