Publish log entry

1 files changed, 64 insertions, 0 deletions

diff --git a/blog/2018/09/17/specification_variable_expansion_in_ick_files.mdwn b/blog/2018/09/17/specification_variable_expansion_in_ick_files.mdwn
new file mode 100644
index 0000000..a8610b7
--- /dev/null
+++ b/blog/2018/09/17/specification_variable_expansion_in_ick_files.mdwn
@@ -0,0 +1,64 @@
+[[!meta title="Specification: variable expansion in .ick files"]]
+[[!tag design]]
+[[!meta date="2018-09-17 20:50"]]
+
+Ick currently doesn't support variable expansion in .ick files at all.
+Sometimes it would be practical for reducing repetition. For example:
+it would be nice to have a pipeline like this:
+
+    pipeline: build_systree
+    actions:
+    - debootstrap: {{debian_codename}}
+    - archive: workspace
+      artifact_name: "{{artifact_name}}-{{debian_codename}}"
+
+Currently, the `debootstrap` action implementation knows about the
+`debian_codename` project parameter. With variable expansion, we don't
+need to have magic, hardcoded parameter, and can be more explicit.
+
+The `archive: workspace` action likewise can avoid using a magic,
+hardcoded variable name.
+
+[Mustache]: https://mustache.github.io/mustache.5.html
+
+The [Mustache][] templating language has been suggested and looks OK.
+I especially like that it isn't Turing complete, making it easier to
+understand the templates. (Jinja2 is Turing complete, and tries to do
+too much. It's also Python specific.)
+
+To add variable expansion support, I propose that we do the following:
+
+* .ick files may use variable expansion in any string value, but not
+  in dictionary keys. This keeps things orthogonal and simple.
+
+* Expansion happens when a build starts. The build resource created
+  will have all values expanded.
+
+* Variables for expansion are all project parameters, and some
+  additional variables defined by the controller. Such variables will
+  initially be:
+
+    * `project` — the name of the project
+    * `buildno` — the build number
+    * `buildid` — the build id
+
+* The value of a variable is converted to a string upon expansion, if
+  it isn't already. Booleans and integers are straigtforward. List and
+  dict values are converted into a normalised JSON representation (but
+  it's not expected to be actually useful).
+
+* We add a "project variable" concept. Each project will have an
+  associated dict, which contains variables the user may set, and some
+  that the ick controller will add or change, such as the next build
+  number for the project. This is distinct from "project parameters",
+  which are set in the project definition. We'll add API calls for
+  this:
+
+    * `GET /projects/foo/vars` — return current variables dict
+    * `PUT /projects/foo/vars` — update variables dict; this
+      updates the whole dict, and will remove variables not in the
+      update
+
+  The controller will add/update the `project`, `buildid`, `buildno`
+  variables in this dict, when a build is triggered. The user may
+  add any variables to the dict they wish.