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. So, in analysing the proposal we believe that you can accomplish this with SNAPSHOTS. You do not need to use timestamped snapshots (which is the main objection in JEP-305) against SNAPSHOTS - you just add -SNAPSHOT on to the end of the version you already have (such that 1.7-rc1652.cd45427eb4e2 becomes {{1.7-rc1652.cd45427eb4e2-SNAPSHOT} e.g. the equivalent command to generate the changelist setting becomes: -Pproduce-incrementals -Dchangelist=-rc$(git rev-list --first-parent --count HEAD).$(git rev-parse --short=12 HEAD)-SNAPSHOT then in the dependencies you depend on the xxx-SNAPSHOT and not the timestamped snapshot version which allows the version to be used from the local repo cache and not to have to download it from the hosted repo (artifaactory etc). Because the changelist produced starts with the ("-rc" git rev list) it becomes monotonically increasing and ends with "-SNAPSHOT" we can garbage collect without any additional tooling. Because it ends in -SNAPSHOT it will not be picked up by canary builds or have the possibility of being included in releases, which will then allow us to include it in the mirror by default so there would be no need to change any settings.xml. If you have a separate artifactory repo to have incremental snapshots then you can just scan this repo to find the latest versions for an update center. It may be possible in artifactory to also change the "snapshots" repo into a group and use routing rules to efficiently serve these whilst still maintaining compatability for users deploying snapshots with existing settings. The change in the JEP of the version being $(git rev-parse --short=12 HEAD) to being $(version.removeEnd('-SNAPSHOT')}-rc$(git rev-list --first-parent --count HEAD).$(git rev-parse --short=12 HEAD) removed a lot of my spider-sense objections... but I think we need to have the deployed version include -SNAPSHOT to get something that aligns with the semantics of the incrementals repo from a Maven perspective Regards /James On Saturday, April 28, 2018 at 2:09:39 AM UTC+1, Jesse Glick wrote: > > A little status update here. > > On Thu, Apr 19, 2018 at 9:27 AM, Jesse Glick <jgl...@cloudbees.com > <javascript:>> wrote: > > I am working on server-side deployment. > > Thanks to the boundless patience of Tyler and others, this is live! > > > https://github.com/jenkinsci/pom/blob/master/incrementals.md#usage-in-plugin-poms > > > describes how to get started in a plugin repository; > > https://github.com/jenkinsci/jenkins/pull/3394 > > would make it work in core. > > To deploy your patch, just make sure the repository is configured as > above, then file a pull request from a repository fork. If build & > tests pass, and the PR is up to date with the target branch, the > artifacts should be deployed for you, and you will see a commit status > check to that effect in the PR. > > At that point you can use the artifacts as a dependency in any other > POM, or download them from Artifactory, or whatever. If you do not > care to wait for the CI builder, you can also build equivalent > artifacts locally, as described in the guide above. > > Note: currently commits on branches in the origin repository do not > get deployed. This should be fixed once a new Git plugin release is > cut and ci.jenkins.io updates to it. > -- 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/315af002-b836-4480-b053-beed9d05eacf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.