On Thu, Apr 19, 2018 at 7:12 AM, Baptiste Mathus <m...@batmat.net> 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 jenkinsci-dev+unsubscr...@googlegroups.com. 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.
