The build scan URL isn't always extracted properly from the logs

[lacasseio]

From this PR (nokeedev/gradle-native#153), we can see that some of the SCAN were not published properly. I'm using this code to attach the build scan URL to the commit/checks.

I'm wondering if we could have a debug flag to try and narrow down what is happening when the action is trying to extract the build scan URL.

[eskatos]

None of the checks on this PR successfully grabbed the scan URL except for the first assemble job.
https://github.com/nokeedev/gradle-native/pull/153/checks#step:6:27
And from a quick look it seems to be the same on other PRs in this repository.
OS doesn't matter, neither the build outcome.
🤔

[lacasseio]

You are right, I was too busy to reply with some more info. Do you have an idea about adding more logs around that part to see if it's the detection of the "Publishing build scan" or the extraction that is the problem?

[lacasseio]

We could also try to just grab the last detected URL (meaning it the last line to start with http).

Another idea would be to capture the last n lines and print them at the end of the build to debug further what is happening.

[eskatos]

One alternative would be to use an init script that captures the build scan URL from the build. It would be more solid.

[lacasseio]

Probably better, to me, it just shows how we should use Gradle instead of action to automate some of this stuff. Anyhow, there was a recent change in GitHub Action where clicking on the detail of a failing job jump straight to the end of the log as well as rendering URLs in the logs as clickable. I'm preferring this from now on, so I will just close this issue.

[eskatos]

Reopening because this is a real issue with the action that I want to see fixed

[britter]

I'm seeing this issue but only on windows: britter/bean-validators#30

I've looked into the code but I don't see anything fishy there. I also added -Dscan.uploadInBackground=false but that didn't fix the problem.

[lamba92]

Same here: https://github.com/JetBrains/jetbrains-gradle-plugins/actions

Each run of the test workflow publishes a lot of build scans. You can notice the flakyness right away!

[etiennestuder]

Extracting the log should happen via buildScanPublished listener rather than via log parsing.