Upcoming JEP for usage of Incrementals repository

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming JEP for usage of Incrementals repository

Jesse Glick-4
On Thu, Jun 7, 2018 at 9:37 AM, James Nord <[hidden email]> wrote:
> whilst it may be a bug that plugin X only builds on Y, it may also be
> completely legit, or too much effort to fix.

I would argue it is never legitimate, though it may be too much effort
to fix. If someone is blocked from building a given plugin (especially
in Essentials) because of operating system issues, then we should
either be investing in containerized tools, or moving some of the
complexity out of the build process and into runtime code. That would
presumably apply to Blue Ocean. If you are talking about a relatively
obscure plugin with one maintainer and a thousand installs, build
reproducibility is indeed liable to be poor.

>> You can check out a commit hash from a fork. GitHub does not really care.
>
> But when we build PRs we likely build it merged with the origin target
> branch thus github has no reference of said hash.

Ah but such builds do not deploy to Incrementals anyway—only when the
PR is fully synchronized with the base branch. (The Jenkins build will
produce artifacts even from an ephemeral merge commit, but the
deployment “function” will reject them and exit early.)

Anyway no one would be referring to an ephemeral merge commit via
version number even if they _were_ deployed, since the ways you might
pick an incremental release version to add to a downstream POM would
be:

· Because you just committed to the upstream repository and expect to
push it and have it be deployed.
· Because you ran `mvn incrementals:update`, which verifies Git(Hub)
DAG ancestry of candidate versions.

> given you may well end up running this
> version in production […] then why not drop the
> "rc" from the version suffix?

Well there is a practical consideration of version number sorting.

1.0 < 1.1-rcNNN.XXXXXXXXXXXX < 1.1 < 1.1.NNN.XXXXXXXXXXXX

so it is deliberate that `-Dset.changelist` switches `1.1-SNAPSHOT` to
something which sorts in the same interval between `1.0` and `1.1`. I
am unsure exactly where actual snapshot versions should sit; if you
know, please advise me in

https://github.com/jenkinsci/lib-version-number/pull/6

since the sorting in Jenkins core is a bit of a mess.

> eventually in production I think you are
> expecting everything to be an rc version (jenkins, plugins the whole works).

TBD. Essentials could define a policy such as: if a plugin commit is
pushed to production (via incremental version) and then some time
period (a month?) elapses with no further changes, it is assumed that
no significant issues were detected by telemetry that required
rollback or fix-forward, so a traditional (MRP) release should be cut
so that even users of the traditional update center will see those
bits.

For Jenkins core, we have traditionally done a weekly release
regardless of what is in it, so if we keep that up, then sometimes the
weekly MRP version would be deployed also to Essentials (since no one
has bothered to push anything since Sunday). For core components like
Remoting, I suppose we would want an MRP version cut prior to the core
weekly if an incremental version were present in the core `master`
POMs, though the process has not yet been nailed down.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2_rJvt%3DZ14qoopfk41_Hf3hyX3HT6NEmcewNb8mDmNWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
12