Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable publishing of incremental builds #627

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

basil
Copy link
Member

@basil basil commented Nov 2, 2022

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 HashMap internally 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 -DskipTests with

diff --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>

@basil basil requested a review from jglick November 2, 2022 21:26
@basil basil marked this pull request as ready for review November 2, 2022 21:26
@jglick
Copy link
Member

jglick commented Nov 2, 2022

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,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I doubt anyone else would want to use this particular configuration.

Comment on lines +1554 to +1555
<rule implementation="io.jenkins.tools.incrementals.enforcer.RequireExtensionVersion">
<version>[1.0-beta-4,)</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could probably be dropped since I guess we do not expect this profile to ever be used inherited, only locally.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +57 to +58
<revision>4.50</revision>
<changelist>-SNAPSHOT</changelist>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine but why not enable CD then? The only reason to hold off was the fear of regressions from incrementalification, not CD per se.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not a fan of the version numbers used in JEP-229 releases.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷 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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

automatically generated change logs

I am confused by that comment in this context, as we already do the same in this repository:

update_release_draft:
runs-on: ubuntu-latest
steps:
# Drafts your next Release notes as Pull Requests are merged into the default branch
- uses: release-drafter/release-drafter@v5

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.)

Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, seems fine so far.

@jglick
Copy link
Member

jglick commented Dec 15, 2022

@basil other than the merge conflict, is there anything holding this back?

@basil
Copy link
Member Author

basil commented Dec 15, 2022

Just additional testing and hesitance to move forward with this given your intent to subsequently enable JEP-229 (which I prefer to avoid).

@jglick
Copy link
Member

jglick commented Dec 15, 2022

hesitance to move forward with this given your intent to subsequently enable JEP-229

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.

@basil
Copy link
Member Author

basil commented Dec 15, 2022

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.

@basil basil marked this pull request as draft December 26, 2022 20:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants