Add testing latest changes using Maven Local #410

ribafish · 2025-07-08T15:00:51Z

Added a Publish to Maven Local and Test with Locally Published Plugin job to Verify Build workflow. This will publish the latest changes to Maven Local, modify settings.gradle.kts to use the locally published plugin and run a regular build, effectively giving us a build, built with the latest changes of CCUD Gradle plugin.

I implemented it by modifying the CCUD version applied to the build to be dynamic (2+). I added this to the build-verification.yml workflow. If you feel this makes more sense to live separately, let me know.

Once this is merged, I will add a similar thing to CCUD Maven and sbt.

… job to Verify Build workflow

.github/workflows/build-verification.yml

jprinet

This certainly works 👍
I am just curious if you considered using a sample project using CCUD as an included build to avoid all the tedious publication process

erichaagdev

Are you going to do the same for Maven too?

FTR, we do something similar to this for the convention samples:

https://github.com/gradle/develocity-build-config-samples/blob/main/.github/workflows/convention-develocity-gradle-plugin-verification.yml

.github/workflows/build-verification.yml

ribafish · 2025-07-09T07:42:09Z

This certainly works 👍 I am just curious if you considered using a sample project using CCUD as an included build to avoid all the tedious publication process

I have, but it kinda seemed nice to apply it to itself :D On a second thought, it might make more sense to have a sample project, esp as I'll do the same for CCUD Maven and sbt if/when this is merged, we just need to agree on what to do.

ribafish · 2025-07-09T08:50:16Z

Actually, I created a sample project and was ready to open a different PR...but I'm not sure I'd include a sample project, in which we define mavenLocal and add ccud with a dynamic version... so, while this current way is more convoluted and hacky, it's still just a test. To me, the sample project should be the way it's supposed to be used. I'm happy to add a sample project, but I still think it shouldn't have mavenLocal and dynamic versions in it.

jprinet · 2025-07-09T10:05:21Z

Actually, I created a sample project and was ready to open a different PR...but I'm not sure I'd include a sample project, in which we define mavenLocal and add ccud with a dynamic version... so, while this current way is more convoluted and hacky, it's still just a test. To me, the sample project should be the way it's supposed to be used. I'm happy to add a sample project, but I still think it shouldn't have mavenLocal and dynamic versions in it.

That's why I would recommend building the sample project with CCUD plugin as an included build, you would get it applied without the need to publish to Maven local, nor specifying the version

ribafish · 2025-07-09T10:29:43Z

Actually, I created a sample project and was ready to open a different PR...but I'm not sure I'd include a sample project, in which we define mavenLocal and add ccud with a dynamic version... so, while this current way is more convoluted and hacky, it's still just a test. To me, the sample project should be the way it's supposed to be used. I'm happy to add a sample project, but I still think it shouldn't have mavenLocal and dynamic versions in it.

That's why I would recommend building the sample project with CCUD plugin as an included build, you would get it applied without the need to publish to Maven local, nor specifying the version

Hm, yes, that's also a possibility...but I still wouldn't call that a sample project 😄 more like integration test project..

erichaagdev · 2025-07-09T13:44:51Z

I don't think we should confuse sample projects and projects used for testing. I also don't think we should use included builds as it's not how the plugin is consumed by users.

What about writing out a minimal build file to a temporary directory and running the test there? Something like this is all you need:

pluginManagement {
  repositories {
    mavenLocal()
    gradlePluginPortal()
  }
}

plugins {
  id("com.gradle.develocity") version "4.0.2"
  id("com.gradle.common-custom-user-data-gradle-plugin") version "..."
}

develocity {
  server = "https://ge.solutions-team.gradle.com"

Then run gradle help.

.github/workflows/build-verification.yml

ribafish · 2025-07-10T11:47:14Z

I don't think we should confuse sample projects and projects used for testing. I also don't think we should use included builds as it's not how the plugin is consumed by users.

What about writing out a minimal build file to a temporary directory and running the test there? Something like this is all you need:

Then run gradle help.

Good idea, probably the least convoluted and clearest among the discussed. I've implemented it, this is the run with it.

erichaagdev

Approved, but left a few suggestions.

erichaagdev · 2025-07-10T17:10:43Z

.github/workflows/build-verification.yml

+          DISABLE_REQUIRED_SIGNING: true
+      - name: Create a test project
+        run: |
+          mkdir test-project


I suggest using runner.temp to avoid dirtying the working directory.

erichaagdev · 2025-07-10T17:12:13Z

.github/workflows/build-verification.yml

+          develocity-access-key: ${{ secrets.DV_SOLUTIONS_ACCESS_KEY }}
+      - name: Publish to maven local
+        id: publish-to-maven-local
+        run: ./gradlew clean publishToMavenLocal -Dgradle.cache.remote.push=false


Did you consider adding the publish to the previous job, then storing/restoring the artifact? That way we test the exact artifact that was build/tested and wouldn't require invoking Gradle here.

gabrielfeo · 2025-07-10T19:04:33Z

.github/workflows/build-verification.yml

+              repositories {
+                mavenLocal()
+                gradlePluginPortal()
+              }


Since this test job should fail if CCUD ends up resolved from the portal instead of maven local as we expect, we could declare that CCUD should be found exclusively in maven local

…ccud exclusively from mavenLocal

.github/workflows/build-verification.yml

+    name: Test with Locally Published Plugin
+    runs-on: ubuntu-latest
+    needs: verification
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Set up JDK 21
+        uses: actions/setup-java@v4
+        with:
+          java-version: '21'
+          distribution: 'temurin'
+      - name: Set up Gradle
+        uses: gradle/actions/setup-gradle@v4
+        with:
+          develocity-access-key: ${{ secrets.DV_SOLUTIONS_ACCESS_KEY }}
+      - name: Download plugin to maven local
+        uses: actions/download-artifact@v4
+        with:
+          name: common-custom-user-data-gradle-plugin
+          path: ~/.m2/repository/com/gradle
+      - name: Create a test project
+        run: |
+          echo """
+            pluginManagement {
+              repositories {
+                gradlePluginPortal()
+                exclusiveContent {
+                  forRepository {
+                    mavenLocal()
+                  }
+                  filter {
+                    includeModule(\"com.gradle\", \"common-custom-user-data-gradle-plugin\")
+                    includeModule(\"com.gradle.common-custom-user-data-gradle-plugin\", \"com.gradle.common-custom-user-data-gradle-plugin.gradle.plugin\")
+                  }
+                }
+              }
+            }
+              
+            plugins {
+              id(\"com.gradle.develocity\") version \"4+\"
+              id(\"com.gradle.common-custom-user-data-gradle-plugin\") version \"2+\"
+            }
+              
+            develocity {
+              server = \"https://ge.solutions-team.gradle.com\"
+            }
+          
+            rootProject.name = \"ccud-gradle-integration-test\"
+          """ > ${{ runner.temp }}/settings.gradle.kts
+
+      - name: Run a build with the locally published plugin
+        id: build-with-local-plugin
+        run: gradle help
+        working-directory: ${{ runner.temp }}


To resolve this issue, we should add an explicit permissions block at the root of the workflow and/or for specific jobs. Since the jobs in this workflow mainly interact with artifacts, Gradle, and Maven, the required permissions are minimal. For instance:

Add contents: read to allow the workflow to read repository contents if necessary.

Add other permissions only if required for the workflow to function correctly.

The permissions block can be added at the top level of the workflow file to apply to all jobs by default or specified individually for each job. In this case, we will add a permissions block at the root level to ensure all jobs share the same minimal permissions.

Added a Publish to Maven Local and Test with Locally Published Plugin…

fb70066

… job to Verify Build workflow

ribafish requested a review from a team July 8, 2025 15:00

github-advanced-security bot found potential problems Jul 8, 2025

View reviewed changes

.github/workflows/build-verification.yml Fixed Show fixed Hide fixed

ribafish changed the title ~~Added selftest with pTML~~ Add testing latest changes using Maven Local Jul 8, 2025

jprinet reviewed Jul 8, 2025

View reviewed changes

erichaagdev requested changes Jul 8, 2025

View reviewed changes

.github/workflows/build-verification.yml Outdated Show resolved Hide resolved

.github/workflows/build-verification.yml Outdated Show resolved Hide resolved

.github/workflows/build-verification.yml Show resolved Hide resolved

Added a way to disable required signing on CI

6891d93

ribafish requested review from erichaagdev and jprinet July 9, 2025 08:51

github-advanced-security bot found potential problems Jul 10, 2025

View reviewed changes

.github/workflows/build-verification.yml Fixed Show fixed Hide fixed

ribafish force-pushed the gk/ghaSelfTest branch from ecb9ad1 to 71174eb Compare July 10, 2025 11:19

github-advanced-security bot found potential problems Jul 10, 2025

View reviewed changes

.github/workflows/build-verification.yml Fixed Show fixed Hide fixed

ribafish force-pushed the gk/ghaSelfTest branch 3 times, most recently from d077948 to 6f5f5f2 Compare July 10, 2025 11:31

Changed the selftest to create a simple project to test with

7b319a2

ribafish force-pushed the gk/ghaSelfTest branch from 6f5f5f2 to 7b319a2 Compare July 10, 2025 11:42

erichaagdev approved these changes Jul 10, 2025

View reviewed changes

gabrielfeo reviewed Jul 10, 2025

View reviewed changes

Changed the selftest to use the runner.temp and made that proj use …

087d538

…ccud exclusively from mavenLocal

github-advanced-security bot found potential problems Jul 11, 2025

View reviewed changes

.github/workflows/build-verification.yml Fixed Show fixed Hide fixed

Made the selftest use the prebuilt artifact from the verification job

ae61886

ribafish force-pushed the gk/ghaSelfTest branch from ce37e8a to ae61886 Compare July 11, 2025 12:02

github-advanced-security bot found potential problems Jul 11, 2025

View reviewed changes

ribafish requested review from erichaagdev and gabrielfeo July 11, 2025 12:04

This was referenced Jul 11, 2025

Added a local selftest to the build-verification.yaml gradle/common-custom-user-data-maven-extension#294

Merged

Added a local selftest to the build-verification.yaml gradle/common-custom-user-data-sbt-plugin#50

Merged

erichaagdev approved these changes Jul 11, 2025

View reviewed changes

ribafish merged commit a7f1903 into main Jul 14, 2025
9 checks passed

ribafish deleted the gk/ghaSelfTest branch July 14, 2025 09:57

@@ -2,6 +2,9 @@
             on: [ push, pull_request, workflow_dispatch ]
+            permissions:
+              contents: read
             jobs:
               verification:
                 name: Verification

Add testing latest changes using Maven Local #410

Add testing latest changes using Maven Local #410

Uh oh!

Conversation

ribafish commented Jul 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

jprinet left a comment

Choose a reason for hiding this comment

Uh oh!

erichaagdev left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ribafish commented Jul 9, 2025

Uh oh!

ribafish commented Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jprinet commented Jul 9, 2025

Uh oh!

ribafish commented Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

erichaagdev commented Jul 9, 2025

Uh oh!

Uh oh!

Uh oh!

ribafish commented Jul 10, 2025

Uh oh!

erichaagdev left a comment

Choose a reason for hiding this comment

Uh oh!

erichaagdev Jul 10, 2025

Choose a reason for hiding this comment

Uh oh!

erichaagdev Jul 10, 2025

Choose a reason for hiding this comment

Uh oh!

gabrielfeo Jul 10, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Check warning

Copilot Autofix

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ribafish commented Jul 8, 2025 •

edited

Loading

ribafish commented Jul 9, 2025 •

edited

Loading

ribafish commented Jul 9, 2025 •

edited

Loading