WIP: convert Makefile to Rakefile and extract util methods to GDK
FYI I started converting gitlab-setup and its dependents task from Makefile to Rakefile during the weekend… this was just an experiment to see if there would be benefits or not, and the resulting of it looks promising…
It’s in a very early stage, I started to identify patterns that can be translated into a simple API so the Rakefile can be read and understandable from someone that can read English and knows a little bit of ruby.
I’ve also extracted some of the configuration part of GDK out of the Makefile into gdk.yml (there are lots of work to do).
My idea is to extract some of the “Framework API” back to the gem, so we use external gems for a few things when needed, an yet doesn’t require the user to run with bundler. So whatever is more “generic” would live inside GDK namespace, inside the gem, and we will use that API to build the Rakefile and supporting libraries.
As two possible examples, reading gdk.yml will be done from that “API” as well as many of the dependencies probings we do like “is informed command available? does this machine have ruby installed? do we have yarn available?” etc… while it’s left for the gdk repository code to implement the checks, customize it with minimal version requirements etc.
That give us the flexibility we have today, but without having to use arcane UNIX language/code. While for many checks, we will still delegate to the existing arcane Unix stuff, we will still be exposing a nice API instead (so we are building the glue/DSL here).
My intention is to ship a viable iteration with no breaking changes (so make gitlab-setup would call our rake task, so people can still use that... we may update gitlab-development-kit automatically on the first attempt and continue to do that in the future when a new version is required, but the workflow should stay the same for the near future).
Also any change on the gem should be backward compatible, so people can upgrade without fear.
Walkthrough
- All code in
lib/gdkis intended to be moved to inside the gem, it's here right now because it's easier to prototype. - We have a
gdk.ymltemplate insupport/templates/gdk.yml.erbthat is the intended place to define new defaults. - Whenever a new parameter is required that doesn't exist yet, we will re-generated based on that file, so upgrades would mean re-generating the
gdk.ymlbased on the template, which makes everybody lifes easier.