Enable publishing of incremental builds#627
Conversation
|
See #462. I was nervous about enabling JEP-305 on this repo, but mainly it just needed testing. |
| A profile that is identical to "might-produce-incrementals" but with "flatten-maven-plugin" | ||
| configured to interpolate variables in the "scm", "url", and "version" elements and keep all | ||
| other elements untouched. This is only intended to be used with repositories like "pom" and | ||
| "plugin-pom". If the POM from these repositories were flattened with the "oss" flatten mode, |
There was a problem hiding this comment.
I wonder if upstream https://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html#flattenMode could use a new value, or is our usage just sufficiently weird to not be of interest to anyone else?
There was a problem hiding this comment.
I doubt anyone else would want to use this particular configuration.
| <rule implementation="io.jenkins.tools.incrementals.enforcer.RequireExtensionVersion"> | ||
| <version>[1.0-beta-4,)</version> |
There was a problem hiding this comment.
Could probably be dropped since I guess we do not expect this profile to ever be used inherited, only locally.
There was a problem hiding this comment.
But that would increase the differential between this profile and the copypasta from which it originated, for no good reason I think. Better to keep all copies of this code as similar as possible I think.
| <revision>4.50</revision> | ||
| <changelist>-SNAPSHOT</changelist> |
There was a problem hiding this comment.
Fine but why not enable CD then? The only reason to hold off was the fear of regressions from incrementalification, not CD per se.
There was a problem hiding this comment.
I am not a fan of the version numbers used in JEP-229 releases.
There was a problem hiding this comment.
🤷 well if this change is released and seems to cause no problems, I will propose CD at some point since the POMs are the last major thing that we have to release manually (Jenkins core being handled specially), and as developer-only artifacts their version aesthetics should be of the least concern.
There was a problem hiding this comment.
I should have mentioned that I am not a fan of JEP-229 more generally. The labeling scheme and automatically generated change logs have long been a source of frustration for me. If I have the choice between using JEP-229 and avoiding it, I will choose to avoid it.
There was a problem hiding this comment.
automatically generated change logs
I am confused by that comment in this context, as we already do the same in this repository:
plugin-pom/.github/workflows/release-drafter.yml
Lines 11 to 15 in 7a900a5
Anyway this is getting off topic; assuming that the testing done for this PR was sufficient, it seems like a clear benefit even while keeping the MRP flow. (On occasion I had tested against timestamped snapshots for proposed POM updates but it gets ugly.)
|
@basil other than the merge conflict, is there anything holding this back? |
|
Just additional testing and hesitance to move forward with this given your intent to subsequently enable JEP-229 (which I prefer to avoid). |
That is an independent consideration. Enabling JEP-229 would simply be a subsuming PR. If you would block that, then I would not bother filing it to begin with. |
|
I would not block it, but ultimately it is a maintainer decision so I think it should be made by whoever is most actively maintaining the repository. |
3 participants
The intended use case of this is to be able to more easily test PR builds of this repository in realistic use cases, albeit with the additional effort of adding a custom
<repository>.Testing done
Compared the differential between the partially flattened (new) https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/plugin/4.50-rc1383.e2d11257662a/plugin-4.50-rc1383.e2d11257662a.pom and the unflattened (old) https://repo.jenkins-ci.org/public/org/jenkins-ci/plugins/plugin/4.49/plugin-4.49.pom and did not see anything of concern. I encourage reviewers to look at this differential for themselves. The only changes seem to be that properties seem to be in a random order (probably going through some
HashMapinternally somewhere) and the elements of the POM have been re-ordered according to the POM Code Convention (which we could re-order in the main branch if we wanted to reduce the diff even further).Verified that I could successfully consume the resulting incremental build in Text Finder plugin by running
mvn clean verify -DskipTestswithdiff --git a/pom.xml b/pom.xml index 9e32894..e7acdfc 100644 --- a/pom.xml +++ b/pom.xml @@ -4,7 +4,7 @@ <parent> <groupId>org.jenkins-ci.plugins</groupId> <artifactId>plugin</artifactId> - <version>4.49</version> + <version>4.50-rc1383.e2d11257662a</version> <relativePath /> </parent> @@ -104,6 +104,13 @@ <id>repo.jenkins-ci.org</id> <url>https://repo.jenkins-ci.org/public/</url> </repository> + <repository> + <snapshots> + <enabled>false</enabled> + </snapshots> + <id>incrementals</id> + <url>https://repo.jenkins-ci.org/incrementals/</url> + </repository> </repositories> <pluginRepositories>