Le mer. 16 mai 2018 à 13:14, James Nord <jn...@cloudbees.com> a écrit :
> So the objection I have is that as it stands in JEP-305 the versions are > releases and these are expected to be garbage collected. > > Anyone also wanting to consume incrementals via a proxy would need to > write tooling to garbage collect releases and there is also the Maven > principal that you never garbage collect releases, let alone the impact > this will have on other pipelines that do canary builds by picking up the > latest **release** of a artifacts/plugins in order to do bleeding edge > testing in our pipelines. And that is also discounting the ability once it > is in our mirror for things to accidentally depend on these releases. > I must confess I had missed reading related IEP-9 when reading JEP-305. I do agree releases should normally be kept basically forever. Now nowadays Nexus, for one, had added a dedicated Scheduled Task <https://help.sonatype.com/repomanager2/configuration/managing-scheduled-tasks> to clean up also releases "Remove Releases From Repository" IIUC (I never used it myself, but did use a lot the other "Remove Snapshots From Repository"). So yes, this shows IMO a pretty usage of Maven, but it shows at least people using Nexus (and I suspect Artifactory can do the same) would normally *not* have to handle that themselves. Now, about the whole artifact collection idea that I had missed: * I think this part in IEP-9 could be just ditched overall, for now at least. As Jesse nicely phrases it below: "until storage costs start to raise eyebrows". IIUC what Daniel told me once, as it stands currently: anyway we never ever remove *any* artifacts from Artifactory, SNAPSHOTs are already kept forever. So I guess the eyebrow would have raised long ago if this was an issue. OK, this could grow possibly faster once Incrementals starts to get used more and more, we /might/ want to revisit then. ** (A possible way to revisit could for instance to better differentiate PRs from merged commits, and maybe more aggressively actually clean up artifacts coming from PRs). * Anyway, people using artifacts for in-house purposes would (should) have put an MRM in place. So they wouldn't even see any issue if an artifact is ever deleted upstream. * We must indeed clearly document that people using Incrementals releases and repository must understand they're adopting a special pattern, and I guess as this is indeed not exposed automatically behing /public or /releases, this is an explicit action that one must not do lightly. So BTW I think https://github.com/jenkins-infra/iep/blob/master/iep-009/README.adoc#existing-maven-repository ought to be completed with a precision saying we *really* must not ever expose http://repo.jenkins-ci.org/incrementals behind http://repo.jenkins-ci.org/public or some other virtual group repository. Keep it separated so that it requires an explicit thinking/action to get used. -- Baptiste -- 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/CANWgJS7RsdVBcWs--j-ftpK%3DsEWXSm7CrzFrzkLStGKBFef3aw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.