Jump to content

Clockwork-Muse

Community Newbie
  • Posts

    2
  • Joined

  • Last visited

Posts posted by Clockwork-Muse

  1. 4 hours ago, dave_k said:

    One step to achieving security of the software supply chain is to cryptographically sign patches or tags and pull requests, as well as releases.

     

    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.

     

    4 hours ago, andy5995 said:

    I haven't worked with submodules enough to form an opinion yet whether or not subs are are PITA. I struggle with sometimes just because I don't use them regularly and forget some of the basic git commands for using them. Based on the little experience I have with them so far, I'm of the opinion they should generally only be used -- and it's when they're most practical to have them included as submodules -- if they are completely independent of the project, such as third-party libraries (although there are exceptions).

    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).

    12 hours ago, Stan` said:

    A few people on linux complained about the presence of windows binaries in the repo, because that makes the download heavier for no reason. The git migration ticket planned to have a download script for the windows plateform just like we can download the spidermonkey tarball. I think this could be acceptable if it works straight out of the box. eg double click on a script would pull all the binaries and update the relevant ones using md5 or sha1 or something.

    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.

    • Like 1
    • Thanks 1
  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.

    • Thanks 1
×
×
  • Create New...