diff options
authordistix ticketing system <>2018-07-03 12:29:07 +0000
committerdistix ticketing system <>2018-07-03 12:29:07 +0000
commit6533834948f78d4695de4b4aabca61edd7939612 (patch)
parent4034021a4f08fe631f651460733caec976db0901 (diff)
imported mails
1 files changed, 127 insertions, 0 deletions
diff --git a/tickets/d20aa3eb7bb042c2ba3912f8086deef7/Maildir/new/1530620946.M848704P5385Q1.koom b/tickets/d20aa3eb7bb042c2ba3912f8086deef7/Maildir/new/1530620946.M848704P5385Q1.koom
new file mode 100644
index 0000000..199194e
--- /dev/null
+++ b/tickets/d20aa3eb7bb042c2ba3912f8086deef7/Maildir/new/1530620946.M848704P5385Q1.koom
@@ -0,0 +1,127 @@
+Return-Path: <>
+Received: from ( [])
+ by (Postfix) with ESMTPS id 4273242C80
+ for <>; Tue, 3 Jul 2018 12:28:30 +0000 (UTC)
+Received: from (unknown [])
+ by (Postfix) with ESMTP id DA2BA4112F
+ for <>; Tue, 3 Jul 2018 13:28:29 +0100 (BST)
+Received: from ip6-localhost.nat ([::1]
+ by with esmtp (Exim 4.80 #2 (Debian))
+ id 1faKQ1-0003WI-QJ; Tue, 03 Jul 2018 13:28:29 +0100
+Received: from [] (helo=somnambulist.local)
+ by with esmtpsa (Exim 4.80 #2 (Debian))
+ id 1faKQ0-0003VU-BO
+ for <>; Tue, 03 Jul 2018 13:28:28 +0100
+Date: Tue, 3 Jul 2018 13:28:26 +0100
+From: Daniel Silverstone <>
+Message-ID: <20180703122826.siolafamphg7mpfo@somnambulist.local>
+References: <>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+In-Reply-To: <>
+User-Agent: NeoMutt/20170113 (1.7.2)
+X-Pepperfish-Transaction: 747b-2b5a-50fa-54c6
+X-Pepperfish-Transaction-By: platypus
+Subject: Re: Making the "git" action in ick more useful
+X-Mailman-Version: 2.1.5
+Precedence: list
+List-Id: discussions about the ick CI system <>
+List-Unsubscribe: <>,
+ <>
+List-Archive: <>
+List-Post: <>
+List-Help: <>
+List-Subscribe: <>,
+ <>
+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
+ick-discuss mailing list