[RFC] Automatic pack assembly

[TheElan]

Your Proposal

Pack should be assembled automatically.

Your Goal

Avoid wasting time and making mistakes.

Your Vision

Do it as a CI job which publishes zips/uploads file to servers.

[TheElan]

from what I understand there are next stages:

1. Get all the jars our repos produce
2. Get ARR jars placed under different urls
3. Merge it with things in main repo (like configs, etc)
4. Create a folder for each specific distribution target
5. Add additional configuration for each distro
6. Zip each distro folder

[TheElan]

@boubou19 :

what we need to sort out for the pack assembling:

• make the script assemble multiple folders:
  • one for technic
  • one for curse
  • one for MMC
  • one for the serverpack
• for the technicpack:
  • assemble the pack
  • pack each mod into a zip with the name of the mod + the new version (@DreamMasterXXL correct me if i'm wrong)
• for the curse pack:
  • make it build the dependencies.json automatically
  • make the stripped version of the pack we can send on curseforge
  • assemble the cursepack (dunno what's going on with that step, but @DreamMasterXXL knows)
• for the mmc pack:
  • make it assemble the pack
  • make it generate a valid and importable archive
• for the server pack:
  -make it assemble the pack with all the clientside mods removed, and some server side mods added
  • zip it with the rest of the stuff used to boot the forge server

[TheElan]

@glowredman :

Another thing that could be a problem: once in a while a mod is removed from the pack. In this case, it should be possible to have it not included anymore in the assembled pack without drastic changes to the system (e.g. deleting a GH repo, removing it from Jenkins, etc.)

[TheElan]

Would want some kind of listings like:

1. Listing with all mods we want to get from our github (can be probably just repo names or https form)
2. Urls to the ARR mod jars
3. Listing of client-side mods (name prefixes should be enough?)
4. Listing of server-side mods (изменено)
5. Listing of version overrides for 1 when we don't want the latest one

Which would live in main repo.

[TheElan]

@Glease

So basically an array of objects like this:

{
  "<some kind of pointer into our maven or github release or jenkins or other sort of download link>" : "https://xxxxxx",
  "client": true,
  "server": true,
  "curseforge": { # or null
    "project": 123,
    "fileID": 456
  }
}

[TheElan]

From what was discussed on discord we would want to write it in some higher level language, and since many people know python and there are handy libs which would integrate with github it is probably a language of choice for pack assembler script.

[TheElan]

From CI perspective to make a github release it needs all artifacts we want to release on github in one folder. We should probably do it on tags or as manual job invocation (here version will be provided as input from user or even better - automatically incremented).

[leagris]

I'd choose a gradle script (Goovy or Kotlin) script to be entirely part of a Jenkins or other CI task.

[TheElan]

I'd choose a gradle script (Goovy or Kotlin) script to be entirely part of a Jenkins or other CI task.

If I would do it I would definitely go with Kotlin

[boubou19]

not groovy please, got a PTSD because of it in buildscripts

[glowredman]

More of a long term goal: Have integration with Solder (what we use for Technic). I don't know what their API allows (in the worst case we would need to modify solder, which I don't know how easy it would be either)

https://github.com/TechnicPack/TechnicSolder

[TheElan]

Also if you need any special environment - CI can run in a docker container, you can even construct and use an image of your own, here is example of a repo which builds and hosts docker image: https://github.com/TheElan/minecraft-1.7.10-ci-docker-image

and here is example of how to add it to CI: SinTh0r4s/ExampleMod1.7.10#47

[TheElan]

Here is a way to download artifacts from latest release on GH: https://blog.markvincze.com/download-artifacts-from-a-latest-github-release-in-sh-and-powershell/

[boubou19]

ok first big issue: solder only accepts get requests on its endpoints: https://docs.solder.io/docs

So i suggest in short term to make all the mods prepacked, so Dream just needs to upload them on solder, and maybe, in the very long term, to modify solder, but it's PHP coded.

The zips for solder must follow this convention: https://docs.solder.io/docs/adding-mods-to-the-mod-library

[bombcar]

Does GTNH run a "solder server" or similar? So we don't actually upload to technic's servers?

[glowredman]

That's how it works, you can't use Technic servers

[boubou19]

yeah, Namikon set up one long time ago.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 3 days

[mitchej123]

https://github.com/GTNewHorizons/DreamAssemblerXXL