I recently had a random idea to fix a problem that evidently only bothers me. It has become de rigueur to litter every project with a random smattering of top-level dotfiles. I’m thinking of the I have designed several systems that use this trope. Yes, I feel appropriately ashamed. My problem is simple: dotfiles clutter my work tree. Given all of the myriad problems with the current state of software “engineering” this particular issue may seem a relatively minor one; however, if this issue is minor, a minor fix may well be all that’s needed. The idea I had recently is to use a Something like: In GitHub, using the example above, In CI (or any tooling hoping to use these configuration files) this namespace can be easily accessed via: A whole There are a few downsides I can think of to this method. Firstly, it’s git-specific; however, I am sure the concept of a branch is not entirely foreign to most version control systems and it could be supported to some degree. In practical terms, supporting git seems to be good enough for most tools. Another downside is opacity. That is, CI files are less discoverable using this method; however, if this style of configuration file were to become the de facto standard then much tooling could be written to surface interfaces for these files and their namespaces. To see posts by date, check out the archives .travis.yaml
-type files that are regarded as a necessary evil to perform some kind of testing or deployment in a particular repo.ref
namespace in git for these files.$ git checkout --orphan CI
$ git rm -rf .
$ mkdir travis
$ cat > travis/config.yaml
language: ruby
rvm:
- 2.2
- jruby
$ git commit -a -m 'Add travis config for testing'
$ git push origin refs/heads/CI:refs/meta/ci
refs/meta/ci
doesn’t appear in the branch dropdown in the web UI, but the ref is stored on the server and accessible by people fetching the repo.$ git fetch origin refs/meta/ci:refs/meta/ci
$ git show refs/meta/ci:travis/config.yaml
language: ruby
rvm:
- 2.2
- jruby
refs/meta/ci
namespace with folders for each service seems so much nicer to me.
To see posts by date, check out the archives
To see posts by date, check out the archives
To see posts by date, check out the archives
To see posts by date, check out the archives
To see posts by date, check out the archives
To see posts by date, check out the archives
To see posts by date, check out the archives
To see posts by date, check out the archives
To see posts by date, check out the archives