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

Build scans are not captured when GE plugin is applied within settingsEvaluated #626

Closed
JavierSegoviaCordoba opened this issue Mar 11, 2023 · 14 comments
Labels
bug Something isn't working
Milestone

Comments

@JavierSegoviaCordoba
Copy link

In this run it is possible to see the scan in the logs

image

But in the summary it is not appearing:

image

https://github.com/JavierSegoviaCordoba/semver-gradle-plugin/actions/runs/4394281726#summary-11932819131

@bigdaz
Copy link
Member

bigdaz commented Mar 27, 2023

Interesting. Does this happen consistently for the project?

If so, can you try to reproduce by adding these init scripts to the ~/.gradle/init.d directory and running the build locally? If you set the correct environment variables, then the script should output a build results file.

@JavierSegoviaCordoba
Copy link
Author

Yes, it is happening on all projects on different workflows. I am using reusable workflows, not sure if that can be the problem.

I don't know what do you mean about reproducing it locally, I haven't developed any GitHub Action before 🤔

@bigdaz
Copy link
Member

bigdaz commented Mar 28, 2023

The way the action captures the build scan is via some scripts placed in the Gradle User Home init.d directory. If you put these in your local Gradle User Home you might be able to debug why they aren't working.

So to reproduce:

  1. Copy the init scripts linked above into ~/.gradle/init.d.
  2. Export the appropriate env vars: RUNNER_TEMP is a directory and GITHUB_ACTION can be any string.
  3. Run the build
  4. Look for a .build-results directory generated in the RUNNER_TEMP directory.
  5. If you don't see it, add some println statements to see where the initialization scripts are failing.

@JavierSegoviaCordoba
Copy link
Author

There is a json file:

GRADLE_ACTION-1680031868132.json

{
  "rootProjectName": "gradle-extensions-project",
  "rootProjectDir": "D:\\Repos\\gradle\\gradle-extensions",
  "requestedTasks": "assemble",
  "gradleVersion": "8.0.2",
  "gradleHomeDir": "C:\\Users\\javøie\\.gradle\\wrapper\\dists\\gradle-8.0.2-bin\\25jlreiuz6u3xu2phlpa2vv4m\\gradle-8.0.2",
  "buildFailed": false,
  "buildScanUri": "https://gradle.com/s/bai43tyy44txq",
  "buildScanFailed": false
}

@bigdaz bigdaz added the bug Something isn't working label Mar 30, 2023
@bigdaz
Copy link
Member

bigdaz commented Mar 30, 2023

Thanks. I think the fact that this file generates for you locally (with a buildScanUri) indicates something amiss in the action post-processing. I'm not actively working on this project at the moment, but will attempt to reproduce/fix this problem before the next major release.

@bigdaz bigdaz added this to the 2.5.0 milestone Mar 30, 2023
bigdaz added a commit that referenced this issue Apr 26, 2023
The `PluginManager.hasPlugin` method was not detecting the GE plugin when it
was applied by a separate custom plugin.
Switching to `PluginManager.withPlugin` fixes this.

Fixes #626
bigdaz added a commit that referenced this issue Apr 26, 2023
The `PluginManager.hasPlugin` method was not detecting the GE plugin when it
was applied during settingsEvaluated.
Switching to `PluginManager.withPlugin` fixes this.

Fixes #626
@bigdaz
Copy link
Member

bigdaz commented Apr 26, 2023

@JavierSegoviaCordoba I finally got around to investigating this. It turns out that the issue was due to the way we detect the com.gradle.enterprise plugin being applied, and the fact that you are applying the plugin inside a settingsEvaluated block.

While I think it's a bit odd to apply a settings plugin during settingsEvaluated, I've found a way to modify our init scripts so they handle this case.

Can you please try running your project with gradle/gradle-build-action@dd/issue626 and check if build scan links are correctly captured?

@JavierSegoviaCordoba
Copy link
Author

How should I apply it?

@bigdaz
Copy link
Member

bigdaz commented Apr 27, 2023

Apologies, I missed the hyphen from the version: you can literally reference gradle/gradle-build-action@dd/issue-626 in your YAML file.
So replace gradle/gradle-build-action@v2 with gradle/gradle-build-action@dd/issue-626.

This will cause your workflow to run with the action code in the dd/issue-626 branch.

@JavierSegoviaCordoba
Copy link
Author

Sorry I was referring to gradle enterprise and how to apply it on settings plugins

@bigdaz
Copy link
Member

bigdaz commented Apr 27, 2023

There's a lot going on in your plugin(s), so it's hard to be definitive.
But I'm not sure why this line is inside a settingsEvaluated block. What happens if you just use target.configureGradleEnterprise()?

@JavierSegoviaCordoba
Copy link
Author

It works, feels free to close it now or when the change is published :)

@bigdaz
Copy link
Member

bigdaz commented Apr 27, 2023

It works, feels free to close it now or when the change is published :)

Will do. Can you confirm that by "it works" you mean that you tried the dd/issue-626 branch and you are now getting build scan links published?

Did you also try moving the plugin application outside of the settingsEvaluated block? Just curious.

@JavierSegoviaCordoba
Copy link
Author

JavierSegoviaCordoba commented Apr 27, 2023

About the scans, they appear in the summary.

I moved it but I haven't tested it yet, I will share it here when the test is done!

@bigdaz bigdaz closed this as completed Apr 28, 2023
@JavierSegoviaCordoba
Copy link
Author

Applying the plugin as you have said works too, thank you 🙏

@bigdaz bigdaz changed the title Build scans are not captured Build scans are not captured when GE plugin is applied within settingsEvaluated Jun 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants