https://gradle.com/ logo
Join Slack
Powered by
gradle 9.1.0 how linux vs macos arm may influence ...
# community-support
k
gradle 9.1.0 how linux vs macos arm may influence on CC? on mac locally i have no problems (beside isVisible), but on linux it listed all runtime as problems. The only difference i see is java toolchain...
v
Can you elaborate a bit, especially with a concrete error message?
k
bit difficult to strip private data, but for example this. local.properties doesn't exist, but report mention it. plugin from composite build uses .toml as usual. And two other systems with same 
clean test
doesn't provide such report.
v
Well, seems the Kotlin plugin tries to read that file at configuration time, so it is CC input. Even if the file does not exist, it is still a CC input, because if the file is created, the CC entry has to be rebuilt.
👀 1
k
is it CC compatible?
Copy code
credentials {
    username = providers.gradleProperty("myuser")
        .orElse(providers.environmentVariable("mypass"))
        .orNull
i guess html listed all inputs, not only problematic
v
Yes, the html should list all. That snippet should be CC compatible yes, but will invalidate the CC entry if the result of the provider changes as you get it at configuration time. Besides that it looks fishy that you assign the password to the username field.
k
that my strip during copy-paste
so how shoul i get the culprit of CC issue? 1019 inputs is not something i can validate manually
v
Depends on how you define "culprit"
If the build fails due to CC problem it yells the culprit at you
k
things that are not compatible with CC
v
Gradle will loudly yell at you
k
mm.. interesting i'm using warn, so it will be un build log? not in html?
v
If something is CC incompatible, the build fails with a hard error
The html is helpful when you for example want to determine why CC is not reused to see what inputs were considered.
k
so this report may be for fresh build also?
v
There might also be deprecation warnings that make the build fail on the next major version upgrade, so always a good idea to address them. But if any CC problems are found, you will recognize it.
so this report may be for fresh build also?
?
k
if i didn't save .gradle between builds
v
Then ... what?
🤔 1
k
then it will miss all inputs from previous build and report them?
May it be that all build is written right, but report is listing all this stuff?
v
It will report all CC inputs whether it is a fresh build or not
It reports the CC inputs, not something that has changed
Besides that CC is not reused anyway unless you cache and restore many things in 
GRADLE_USER_HOME
or preserve it between builds. It might still make your build faster (or slower) due to the parallel task execution (serial dependency downloading) even if the CC entry is not reused though.
k
userhome is preserved, but i have only one setting in it - disable gradle daemon, because subsequent builds may have different versions
v
userhome is preserved
Ah, ok, thought you said it is not preserved
disable gradle daemon, because subsequent builds may have different versions
That is actually a quite bad reason to disable the daemon, I don't get the reasoning o_O
k
I finally got what misslead me. Log says Problems report is available at: ..... problems-report.html internally it says "no problems", but lists all inputs. After isVisible i thought all entries are problems
v
problems report != configuration cache report
🤔 1
The problems report is the report about the problems reported with the new Problems API afair. The configuration cache report is a report about the CC inputs. If there is a CC problem, the build fails.
😅 1
k
configuration-cache-report.html right. and their "UI" is 1-to-1 😄
Hehe i would say that CC report should have "problem" word, but "problems report" would be just "build report" in my case it has 0 problems, only lists all inputs. So there is no issues with the build.
v
And why would you say that? The CC report lists CC inputs, not CC problems, so why should it have "problem" in the name? The problems report on the other hand shows build problems, not some build report, so why should it miss that in its name? Doesn't make much sense to me.
3 Views
Open in Slack
PreviousNext
Powered by