Very many different CI standards exist for testing code, and for building it. If people make automatic steps for their CI or their build server, they should be integrated into a git subcommand (like gpg signing / submodules), and a standard format, like docker-machine.

Docker Machine provided the benefits of the ability to move between VPS’s. This was amazing because you no longer needed to learn the API of each host you moved to, you only needed to set up tokens.

Docker Machine, however, doesn’t help with running things in custom engines, like google’s raw app infrastructure (but does run on their container infrastructure). It’s also very standardized and while I’m really happy about it, it has things to improve on.

Many technologies for constantly deploying repos are fragmented, using different formats. They all have the same goals:

  1. use safe credentials
  2. set up a build environment
  3. run a build
  4. run tests
  5. store an executable
  6. deploy an executable
  7. notify you about how it went

They have various settings, and everybody innovates something new into that syntax, but limiting us to the same test environments by virtue of configs is a bit annoying. Ignore the keys you don’t know about, and use fallbacks.

Don’t try to make every test framework (for example, across nose2 or gradle) run the same, but do, please, for the love of /proc, make your “setup-run-report” format exactly the same.

Testing should be sewn into git to reinforce that any repo, without modification, should be testable on any CI service, or deployable to any hosting service, without changing the configs.

To make a subcommand of git, simply make an executable script and place it in /usr/bin/git-<foo>, for example:

#/usr/bin/git-ci
print("Standardized CI Executor")
# git ci

Immediately, I can think of unifying the container format and placing it in a .gitvm folder, or at the very least having a config/version file tell which format the containerfile is, and where it’s kept:

format="docker"
file="/Dockerfile"
base="/"

For CI, it’s a bit tougher, as they all like to have their various options: .gitci would contain a version file with the following options:

tester: company/golang-tester #a tester image
fail: deadly