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.
