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: fix mystery Artifactory issue #4945

Merged
merged 3 commits into from
Nov 8, 2021
Merged

Conversation

Cervator
Copy link
Member

@Cervator Cervator commented Nov 8, 2021

So today Nov 7th for no discernable reason Gradle stopped being able to resolve snapshot dependencies from our Artifactory instance. I was able to replicate it locally in a handy workspace I hadn't touched since June, so it wasn't anything we changed anywhere, including Artifactory really - it is rarely ever touched and hasn't been upgraded for years (doing so is on a todo list somewhere).

Closest guess I can make is that it is an Artifactory OSS vs Pro feature: https://www.jfrog.com/confluence/display/JFROG/Artifactory+REST+API#ArtifactoryRESTAPI-RetrieveLatestArtifact - supposedly automatically fetching the latest incremental version of a snapshot is a Pro feature. Who knew? We've been using it in the OSS version since day 1! No idea how that has worked so far if the docs are accurate.

Ultimately it turned out to be "blocked" (if saying so is really accurate, I dunno) in the virtual repository definition in Artifactory (the "virtual-repo-live" thing that is a proxy collection of a bunch of repos, internal and external) yet if you explicitly call out the snapshot repo path itself (terasology-snapshot-local) then somehow it works fine. So this adds that to our Gradle. I've adjusted it in the Index repo already, after testing it with a Nanoware Omega build. It may be needed elsewhere - say if we rely on a snapshot library dependency somewhere. But at least this gets the game building again.

Lost in the shuffle is the dynamic nature of swapping between the "live" virtual repo and the Nanoware variant that specifically excludes the terasology local repos in favor of nanoware local repos so you can do Artifactory testing in isolation. That'd TODO to make conditional, or maybe there's some more clever way to overhaul that if we just go to Nexus already?

It has been a day so I'm going to leave it at that. I've tested the change and am confident in it, note that no module builds (with dependencies) will work until this PR is merged.

Also, don't forget to squash merge this - the first commit is titled correctly, the rest not so much ;-)

Edit: I should mention that while troubleshooting I noticed that the remote repos configured in Artifactory (so proxy repos, essentially, so we could request things from say Maven Central through our virtual repos) are probably all broken at this point, being that they were configured 5+ years ago. Most URLs are no longer good, the Maven central one was, but the log had complaints about lacking HTTPS (in our definition of the Maven Central repo, not actually about our poor HTTPS-less Artifactory). I tweaked that one address to https and am not sure if that helped the logs. We directly configure Maven Central etc within Gradle so we don't need to rely on pulling it through Artifactory (typically more of an enterprise thing)

Also, a bit of testing proof: https://jenkins.terasology.io/teraorg/job/Nanoware/job/Omega/job/develop/43/console

@Cervator Cervator added Category: Build/CI Requests, Issues and Changes targeting gradle, groovy, Jenkins, etc. Blocker Issue reporting or PR addressing a critical problem that blocks other efforts labels Nov 8, 2021
Copy link
Member

@keturn keturn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for running this one down. Very vexing.

We might have to tweak the repository order if this slows things down, but let's get builds running again and see.

@keturn keturn changed the title Fix mystery Artifactory issue build: fix mystery Artifactory issue Nov 8, 2021
@keturn keturn merged commit 7dfebd3 into MovingBlocks:develop Nov 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Blocker Issue reporting or PR addressing a critical problem that blocks other efforts Category: Build/CI Requests, Issues and Changes targeting gradle, groovy, Jenkins, etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants