On Wed, Jun 20, 2018 at 18:00:43 +0300, Lars Wirzenius wrote:
Hm. Supporting something like jinja2 in the controller is something
that may become necessary later on, but it's a complication that I'd
like to avoid until it is necessary to have it. Even if that means
more verbose .ick file. I guess it'd be possible to only support it
icktool, but I'll have to think about this.
Supported in icktool and then uploading specialised pipelines would be
Is your example really saving much typing? Since parameters are per
project, the following stanza would need to be repeated for each
doh, I meant for that to be part of a git pipeline step, and for source_name to
be one of the parameters set in the project. I was not explaining myself well.
I recognize that the .ick files get rather verbose as they are
currently defined. For the immediate future, I prefer that over a more
complicated controller. Later on, as we (as the ick project) gain more
experience of what the pain points are, we can make the .ick language
It's possible that perhaps Yaml anchors and dictionary merges might help with
some of this.
Maybe we can make the .ick language more powerful with better
defaults? Perhaps by having a "default parameters for all projects"
section? Also, sets of pipelines for different styles of projects?
No templating complexity, but rather less repetition. It's not
generic a solution, of course. What do you think?
I think that introduces a little bit too much magic into the git action,
and another keyword (style) which I'm not convinced by. For now let's
stick as we are, and we can always consider preprocessing with jinja2
in icktool or similar at a later date.
At worst, for now, I have a shell script generate my ick file from a bunch
of snippets and running sed :-)
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69