Making the "git" action in ick more useful

Daniel Silverstone dsilvers at
Tue Jul 3 13:28:26 BST 2018

On Mon, Jul 02, 2018 at 18:24:48 +0300, Lars Wirzenius wrote:
> However, the above design isn't flexible enough for Daniel, who needs
> to access multiple git repositories, not just once, and build a tree
> of clones. I'll let Daniel tell us what his use-case is like. (I think
> I know, but it's better if he tells it himself. I can be a bit of a
> broken telephone.)

So I have a couple of personal use-cases.  One is covered by the above
and one which isn't.  I have a third use-case which is so "out there"
that I doubt we'll be able to cover it usefully, but I'll mention it
just in case :-)

So, my primary non-covered use case is for building packages for Gitano
and its related projects.  To do this, two git repositories have to be
checked out which are project-related, and one which is shared tooling
for building the packages.

I have many projects, luxio, lua-scrypt, clod, gall, supple, lace, tongue,
and gitano, all of which can be built with essentially the same pipeline
stages, so long as they are parameterised by the project name.  As such,
my projects have a reponame parameter.  Given that, if we assumed that
the git action could be parameterised in the pipelines:

- action: git
  repo: "git://{{ reponame }}.git"
  ref: "{{ refname }}"
  path: "{{ reponame }}"
- action: git
  repo: "git://{{ reponame }}/debian.git"
  ref: "{% if debianrefname %}{{ debianrefname }}{% else %}{{ refname }}{% endif %}"
  path: "{{ reponame }}/debian"
- action: git
  repo: git://
  ref: master
  path: gp-packaging-tools

would be approximately what I'd need for my git checkout pipeline.

If "optional" parameters is not a thing, then the debianrefname parameter would
just have to be provided at all times, defaulting to master as refname would.

If, on the other hand, the ref was irrelevant because it was expected that
there'd be a stage doing `git checkout ${refname}` or similar later, then I can
handle the case of debianrefname being empty/not-provided in shell.

My "out-there" use-case is what I call, in Gitano, system branches.  That works
by having branches of the same name in any/all of the above repos, and then
they're checked out together (along with master for any repo without the
branch) and all built together for test purposes.  This project would not
produce any debs because it purely exists to prove out the test suite on a
system other than my development system, and I have tooling to produce the
checkouts and build the code, providing that it can run somewhere with network
access.  We'd need something like:

- action: git
  repo: "git://"
  ref: "{{ sysbranchref }}"
  fallback-ref: master
  path: gitano

Where fallback-ref is checked out if ref isn't available in the remote.

I don't know how much of this you, or others, would want in Ick, but there you
have it.

For me, the obviously desirable option is (a) that the git action can take
repo, ref, and path directly in the pipeline stage, and (b) that we can use
some kind of syntax to interpolate parameters into those strings (using jinja2
seems obvious, though requiring that at the ick controller end might be a
smidge iffy for maintaining the possibility of replacing the python
implementation in the future).

I look forward to your take on all the above,


Daniel Silverstone               
PGP mail accepted and encouraged.            Key Id: 3CCE BABE 206C 3B69

More information about the ick-discuss mailing list