Move those files to Unvanquished ?

[illwieckz]

I always find annoying that those files are in a separate repository.

Also some scripts versions may be somewhat version-specific (we modify the script and commit the modification when the game requires it).

[necessarily-equal]

Not sure, but they certainly could be with https://github.com/Unvanquished/validate-release.

[illwieckz]

Yes

[necessarily-equal]

I thought about this a bit, and seen #24. I'm thinking that if we want to make cmake able to build a dpk it could be useful to adapt those scripts if needed instead of writting yet another implementation.

So moving this to the unv repo would be useful if we want to reuse it (CC @bmorel since you were talking about cmake dpk yesterday)

[illwieckz]

Also the build-release script is expected to be executed while being in Unvanquished repository, this way:

git clone https://github.com/Unvanquished/release-scripts.git
git clone --recurse-submodules https://github.com/Unvanquished/Unvanquished.git
cd Unvanquished/
../release-scripts/build-release vm

That looks overly complicated to me. We could just do:

git clone --recurse-submodules https://github.com/Unvanquished/Unvanquished.git
cd Unvanquished/
utils/build-release vm

[illwieckz]

Also we don't need “one repo per script” or almost that.

[ghost]

Since I was mentioned...
multiple repos and submodules are just a pain.
If those scripts are for building unvanquished, host them in unvanquished. If they're for building daemon, same, but with daemon. If they're for CI, then I'd say CI requires it's own repo (I guess it already have it) and those should be there.

[slipher]

The Docker script downloads the Unvanquished repository inside the container. So to use it, you would perversely have to download the Unvanquished repo once to get the Dockerfile and then a 2nd time inside the container.

I'm not saying this is a killer argument against merging them, but putting it here for your consideration.

[DolceTriade]

We could update the docker script to mount the current directory instead of cloning the git repo

[slipher]

We could update the docker script to mount the current directory instead of cloning the git repo

For me part of the appeal of the Docker script is that it ensures that the builder doesn't have uncommitted junk or the wrong submodules checked out. You know you're getting what's actually in Git.

[illwieckz]

@bmorel: If those scripts are for building unvanquished, host them in unvanquished. If they're for building daemon, same, but with daemon

The dæmon repo is also a good candidate as this script is to build both dæmon engine and dæmon-based games.

In fact, right now the only hardcoded mentions to Unvanquished in this script is some macos stuff that may even be redesigned to be more agnostic. Anyway getting this in Unvanquished would already be a good step forward.

The Docker script downloads the Unvanquished repository inside the container. So to use it, you would perversely have to download the Unvanquished repo once to get the Dockerfile and then a 2nd time inside the container.

Even not considering we need to download the Unvanquished repo for macOS (if we find way to avoid that, I'm in to remove that restriction), yes there are some convenience in the fact the docker file is in a small repo.

This build-release script can be used every day for packaging mods and having this in a second repository is making it almost unused outside of release and is making it harder to keep it in sync.

If I'm right the docker file runs this script, not the other way, so we may even move this script to Unvanquished or Dæmon and get the Dockerfile run the script from there. I see less needs for the other scripts to be moved into Unvanquished or Dæmon. The other one for making the unizip has less urge as well.

People are complaining for long time doing a mod isn't easy, build-release being part of Unvanquished/Dæmon and #24 (mod building) being merged would make it much more convenient for people.

[ghost]

So to use it, you would perversely have to download the Unvanquished repo once to get the Dockerfile and then a 2nd time inside the container.

I'm usually a strong opponent to submodule (ab)use, but, one of the advantages this have is to pull dependencies. Currently, I think the CI stuff is inside unvanquished repo (appveyot), and I usually consider this as an entirely different project, which modifications have very little in common with the actual program (thankfully on unvanquished the code history is not too polluted by changes there... for some projects there are most CI stuff than code stuff I feel!).
So, my point is that those repos:

• release-scripts
• validate-release
• unvanquished-documentation-data (maybe)

could possibly be a single repo (unv-build?), that would also contain CI, and have unvanquished + the pkg/ stuff as submodules. It's role would be to handle everything lined to CI/CD and releases, possibly also the scripts @necessarily-equal did for the generation of servers and nightly maintenance.
CI/CD and release stuff, in short.

[slipher]

Docker and build-release should definitely not live in different repos as they are tightly coupled. Having them be together is much more important than not downloading the repo twice, which is more of an aesthetic issue than a real problem.

I haven't heard of any project putting CI in a different repo and I don't see how it could work. We need CI to trigger on changes to the Unvanquished or Daemon repos; having those as submodules of a CI repo would mean that the references to test would be hard-coded.