Jump to content

Clockwork-Muse

Community Newbie
  • Posts

    2
  • Joined

  • Last visited

Everything posted by Clockwork-Muse

  1. This would not, in any way, prevent a SolarWinds scenario - the releases were properly signed in that attack. You'd have to have a second, separate, build chain rebuilding releases to compare output hashes to catch it. What I personally tend to prefer is uploading private (as in, not widely published, not that they're hidden) package repositories. Gitlab, at least, has several built-in package repositories (NuGet, maven, PyPi) that can be used for uploading/hosting these kinds of things, and I believe several other CI systems do as well. And in some cases that's not necessary - recent versions of cmake, I believe, can grab git repositories as project includes (assuming the referenced project also uses cmake). I personally feel no build output should ever be persisted to a repository, and no third-party binaries if you can avoid it. Back when I made my few contributions and also saw the earlier git/svn debates, my feeling was that an artists'/testers' script was the way to go, too. I think my only recommendation here is to make it so that you could pass version numbers to be able to work against a particular build (just stating what I assume was implied). For that matter, it's possible to install hooks into various parts of git (I don't know about svn, but possibly there too) - UnrealEngine, for example, has a script that you're supposed to execute on first clone; thereafter, any time you switch branch or pull updates, it downloads the relevant third-party dependencies and common content. I personally prefer working with git, being a programmer, because it makes diffs and branching so much easier for text assets. In most common cases, assuming submissions are based on branches/pull requests (instead of submitted diffs), there's usually not much visible difference between git and svn, though - it's only once you have multiple people modifying the same file that git and prs really help. Other than switching typing `svn` for `git`, I don't think artists would really be affected.
  2. Part of the problem migrating is that there's a bunch of stuff in the repository that shouldn't be in a code repository at all. Plus We have all of the "default" 0AD mod/resources in the same repo as all engine code. These are really orthogonal, and belong in separate repositories. We have many dependencies in the repository. These do not belong in a code repository, but some sort of binary repository/dependency management system (eg, Nuget in the C# world, or maven for Java). C++, however, has not traditionally used one of these systems. The final, built binaries, are in the repository. Ideally, we should probably be doing something like: Git repository for main engine code (+ some small default resources). This can be self-hosted, or use an existing provider and backup a copy every day. Dependency management repository for code artifacts. There are some out there for C++, although we will likely have to host at least some of our own. Git repository for the "default" 0AD mod code Repository/ies for art source files. Note that the goal would be to have no "built" items in a live repository, instead: Dependency management repository for built art files. This also gets used by: Binary repository that combines art files and mod + engine code into the finished product. .... which would be quite some work to set up. I think the best first step, though, would be to start getting dependencies out of the main repository and into a package management system.
×
×
  • Create New...