On Wed, Nov 17, 2021 at 4:05 AM Tim Jacomb <timjaco...@gmail.com> wrote:
> That's assuming that the gradle plugin supports incrementals which I don't
> know if it does.
>
It does not, and the whole concept is rather specific to Maven.
Stepping back, there are basically two sides to JEP-229: a backend patch to
the RPU processor whose sole purpose is the provisioning (and rotating) of
a GitHub secret in your repo which allows Actions in that repo to deploy to
the associated paths in Artifactory, when `cd.enabled = true`; and various
components under your control (a Maven extension originally created for
JEP-305 Incrementals, conventional Maven metadata edits, a stock workflow
with a couple specialized Actions) that cause pushes to trunk to
automatically trigger a `mvn deploy` and publish a GitHub Release based on
Release Drafter when there have been “interesting” changes.
One thing which should be possible in principle, but which I have not had
reason to try, is to use MRP with the backend part. You would create a
manually triggered workflow which just runs `mvn -B
release:{prepare,perform}`. The `$GITHUB_TOKEN` has write permission, so it
can push the two junk commits MRP generates as well as pushing the tag.
This could be integrated with Release Drafter or the release/changelog
aspect could be manual. You would not get the CD system, but you would at
least not need to have personal credentials to Artifactory, and there would
be no need to change anything else about plugin sources (would use the
traditional manually-maintained version scheme). Basically take your
existing local release command and wrap it in a workflow which just binds
the Artifactory authentication but otherwise makes no process changes.
I presume the same would apply to Gradle-based plugins, using whatever
command it is you use to perform releases from Gradle. This would be an
easy step. If you wanted actual CD for a Gradle-based plugin you would need
to put some thought into what that would look like, especially in terms of
version maintenance and overall experience.
Remember that even without JEP-305 you can trivially deploy a Maven-based
project in a CD style. You pick one of the three magic property names that
Maven allows in `version`, and override it from a deployment script. Thus
configure your POM
<version>${revision}</version>
<properties>
<!-- fallback so local dev builds do something -->
<revision>0-SNAPSHOT</revision>
</properties>
Then pick a version during deployment automatically, via human input,
whatever, and:
version=$(date -u +%Y%m%d%H%M%S)
mvn -s settings-referring-to-MAVEN_TOKEN.xml -B -Drevision=$version
-DaltDeploymentRepository=maven.jenkins-ci.org::default::
https://repo.jenkins-ci.org/releases/ -Pquick-build clean deploy
gh api -F ref=refs/tags/$version -F sha=$GITHUB_SHA
/repos/$GITHUB_REPOSITORY/git/refs
(I am passing `-Pquick-build` here under the assumption that tests are
already run by ci.jenkins.io, which JEP-229 systems enforce, and would be
redundant here. You can omit it if you do not wish to make that assumption
and you know your tests are able to run inside the workflow.)
This works fine for a self-contained project: one whose only consumer is
the update center, paying attention solely (I suppose) to the
`*.hpi!/META-INF/MANIFEST.MF`. It does not work well if any other project
might declare a dependency on it, if the deployed POM is used for any
purpose, if it might be run via `plugin-compat-tester`, etc., which is why
JEP-305 is so tricky. I really am not sure what considerations apply to
Gradle-based projects.
--
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/CANfRfr02NVPau4AcPbryV6b7YqyQU1vTObzmn_rcGMTXAnFa-A%40mail.gmail.com.
