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
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
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

-- 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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to