https://gradle.com/ logo
Join Slack
Powered by
only happening since 9.2, the weird thing is it's ...
# community-support
c
only happening since 9.2, the weird thing is it's not happening locally although I got an even weirder first run error locally. It might be related
Copy code
java.lang.IllegalArgumentException: Cannot have abstract method FileSystemLocationProperty.getAsFile(): Provider<File>.
full stack/repo https://github.com/xenoterracide/gradle-semver/actions/runs/18941346345/job/54080662841?pr=494#step:5:437
Untitled.java
m
It looks like something may be broken with 
ProjectBuider
. You're saying, the test only fails on CI, but passes locally? What is the first run error?
c
There is an entirely different error that I got on first build locally that has something to do with locks and generating jars I'll have to get it later this evening. As far as I know this error happens on every single run in CI but I never got the generating jars error in CI
m
It is probably worth filing an issue, though we'll also need a reproducer, and building the original repo is a bit convoluted to serve as such :(
c
yeah, that's pretty unlikely for me to spend unpaid time on finding a minimal reproducer for this regression unfortunately. I don't think the original repo is convoluted... it's not simple but I feel like it's closer to real world setup. Why exactly is it convoluted? because for some reason I didn't think to do this this morning, here's a build scan with my local exception https://scans.gradle.com/s/fkv2dt3jqjowu
oh, and I forgot, in case it wasn't seen... my CI builds also publish scans https://scans.gradle.com/s/ugjlok7t2bkma
v
"convoluted" probably because you cannot simply clone and execute the build, because you at least need to provide GitHub credentials, and a security sensitive user will not lightly give his GH credentials to an unknown build that could do anything with those credentials. That's the major point why I massively dislike the GPR and would never use it in its current state.
c
oh, yeah I hate it too but I'm not going to publish to maven central and I don't think gradle plugin portal has the ability to give let us publish pre-release in a way that is sanely supported IIRC
so, I mean, java community problem?
where should I publish nightlies?
also, I've found I have to dogfood plugins immediately or stuff breaks, existing test infra is not great
v
You could push nightlies to Sonatype even if not releasing to Maven Central in the end? 🤷‍♂️
c
is that free?
v
Yes
c
and nobody would need credentials to access those?
v
No
You "just" have to register for your namespace on Central Publishing Portal and then there enable snapshots. Then you can use 
maven-publish
to publish to 
<https://central.sonatype.com/repository/maven-snapshots/>
and your users can use that very same address to resolve your snapshots without any credentials or fine.
c
yeah but I don't use actual snapshots because those aren't stable...
non reproducible!
it's actually argubably the feature of my semver plugin
reproducible build
v
Ah, yeah, non-snapshot pre-releases is maybe not optimal
c
and you know, if I paint builds as 
-alpha
clients will handle it fine, it's just a lot of garbage to put on sonatype
v
Your users could use JitPack for pre-releases, but JitPack comes with its own shitload of problems, but as long as it is just for pre-releases / testing arbitrary branches or commits, it is usually fine.
c
jitpack?
also, I have users?
v
Well, whom would you release prereleases for otherwise? 😄 If it is just for yourself you can just publish to a local directory-based repository and consume from there.
Something like 
mavenLocal
just without its problems
c
me, for dog fooding
if it's not in CI, it doesn't work
like, I caught this build error trying to auto upgrade gradle in my sleep
v
JitPack is a service where you can request any GitHub project (that is not failing to build on JitPack) that uses a supported build system and request any tag or branch or even commit SHA. If it did not build that version yet it gets the sources, builds the project and then delivers it. It is a build-on-the-fly Maven repository.
c
and had the merge happened it would have built an artifact, pushed it and then the next auto update would have dog-fooded that
v
I see, well for pure self-consumption on GHA using GPR is probably fine. Unless you then have problems you want someone to have a look at. Why I did not answer a few hours ago was because I was not able to have a look easily without giving my GH credentials to an unknown build. 🙂
c
lol
v
And just copying out the value source code and using it in a 9.2.0 build just worked fine
c
yeah, I totally believe that's a red herring
ugh, I don't know why it's doing that
I've only been typing enter
v
Because you accidentally checked the checkbox under the message box
c
I guess, oops
v
You can just delete it from the channel and the message here will stay
c
has anyone ever wanted that setting?
v
Happened to me also, in the past 🤷‍♂️
Sometimes the setting is useful
If you post some important update, or a followup question that is better asked in the context of the thread but that should get some fresh attention
c
maybe it should be less easier to click?
v
Definitely
c
anyways...
v
But I've given up asking Slack for things, it is harder to get them than from Gradle
There you can at least contribute them yourself in the end
c
the real answer to the credentials thing is probably to fix the dogfooding problem, I've found gradles built in test stuff was not good enough to avoid bugs
well... slack is proprietary...
and we should ask ourselves... why has the FOSS community not given us a better slack/discord/teams
or if they have, why do we not use it
anyways... dunno what to say about putting credentials into strange builds... feels like a problem gradle should think about
along with maybe providing a friendly solution to publishing "nightly" plugins
v
You have a web server, you can publish your nightlies there. 😄 It's probably too much to ask for from Gradle to additionally provide free infrastructure for nightlies. 🤷‍♂️
c
I don't have a web server 😉
v
Well, somewhere your blog is running
c
I have a cdn...
it's running on vercel
I mean, I could publish might "nightlies" to other places, I'm just being all respectful
like nothing really prevents me from pushing to the plugin portal
v
except your decency
👌
c
exactly
v
🙂
c
I don't like abusing things
❤️ 1
(kind of, I don't care how many jobs on github I run! but I don't actually hit the free minutes)
in any sense... it wouldn't surprise me ot find out that the 2nd scan might explain the first error somehow
or... err.. the local error rather
also, pretty sure if you're trying to avoid credentials you could
Copy code
maven("<https://maven.pkg.github.com/xenoterracide/gradle-semver>") {
      name = "gh"
      mavenContent {
        includeGroup("com.xenoterracide.gradle.semver")
        includeModule("com.xenoterracide.gradle", "semver")
        includeGroup("com.xenoterracide.gradle.git")
        includeModule("com.xenoterracide.gradle", "git")
      }
      credentials(PasswordCredentials::class)
    }
remove this and rewrite the lock files and be good to go
since there are published versions of everything and I use dynamic ranges
oh, no, not until I actually publish tools somewhere instead of embedding it
forgot about that
v
but I don't actually hit the free minutes
That's easy for a public repo, there the free minutes are ∞
c
Did they change that? Last time I checked it was like 2K...
Either way I don't care about GitHub I think Microsoft will be fine
v
No, was always like that
2k is for private repos
public repos don't have a limit
c
I feel like there was a point in time where I actually hit a limit. 🤷🏻‍♂️ I don't really have private repositories and I don't think I ever have. 🤷🏻‍♂️
I could be wrong but this isn't really the issue we're talking about
v
Well, the only instance I remember hitting such a limit was when I played with something in a private repo before wanting to make it public and making it public fixed it. And I cannot remember this ever being different. 🤷‍♂️
And yeah, it isn't
Speaking of that, the "strange error" from your first scan seems quite meaningful
c
Doesn't really matter does it
v
You had two Gradle processes running
And the second timed out waiting for the lock to generate the file the first process was still generating
Once that process was finished generating that file, the error will not come back, because the file is already there
c
Yeah but as far as I know I didn't start two processes... Only seems to happen when I hit rerun tasks. Not really sure of cleaning everything out is also needed
But it's definitely consistently reproducible
Locally anyways. Maybe the other process is intelliJ
Either way didn't happen before the most recent upgrade
v
Maybe. Or maybe you start mutliple processes by running the integration tests
Maybe before there was no locking on that action and that caused other problems? 🤷‍♂️
c
Yeah quite probably that too... I mean my integration tests run concurrently and however the integration project runner would create those ...
mediocre effort! https://github.com/gradle/gradle/issues/35526 turning off concurrent tests made both problems go away
👌 1
4 Views
Open in Slack
PreviousNext
Powered by