Prerequisites for Artifactory & Jenkins migration/upgrade #5293
+69
−12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes an apparent syntax issue in a newer Jenkinsfile and attempts to refresh the support to test a different Artifactory URL via alternativeResolutionRepo in a gradle.properties copied (manually due to something else that broke) from the templates directory to the project root
Tested over at https://jenkins.nanoware.us/job/repatriation/job/terasologyengine/job/mbdev/ (building Nanoware/Terasology/mbdev) as infra migration / upgrades are sort of tricky to test normally. Plus the Nanoware org job line in the current Jenkins is actually empty, partly because moving from the fancy Cloudbees Jenkins lost us a plugin that let you set easy properties at the folder level - which allowed all Nanoware jobs to automatically swap to a different set of Artifactory registries :-(
Or rather, lol, it would be tested there, but apparently I've run up against an SSD quota within GCP since I have two 200 GB Jenkins disks and some smaller stuff (including the build agent for the current test) and apparently the default limit is 500 GB? Who knew. Submitted a request to increase and will also decrease the Jenkins disk as we haven't needed that much space for a long time at this point.
Odds are this PR will fail testing here, and I may have to merge it on the spot when I get a chance to try swapping DNS over to the new stuff to start validating and rebuilding all the things. I count it a breaking change not to the game but logistics-wise - some stuff is likely to blow up till everything is trickled out to everywhere.
I've largely kept https://github.com/MovingBlocks/Logistics/tree/repatriation updated with new infra config and docs, but there's a bit more to come