Return-Path: X-Original-To: distix@pieni.net Delivered-To: distix@pieni.net Received: from yaffle.pepperfish.net (yaffle.pepperfish.net [88.99.213.221]) by pieni.net (Postfix) with ESMTPS id 4273242C80 for ; Tue, 3 Jul 2018 12:28:30 +0000 (UTC) Received: from platypus.pepperfish.net (unknown [10.112.101.20]) by yaffle.pepperfish.net (Postfix) with ESMTP id DA2BA4112F for ; Tue, 3 Jul 2018 13:28:29 +0100 (BST) Received: from ip6-localhost.nat ([::1] helo=platypus.pepperfish.net) by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian)) id 1faKQ1-0003WI-QJ; Tue, 03 Jul 2018 13:28:29 +0100 Received: from [148.252.241.226] (helo=somnambulist.local) by platypus.pepperfish.net 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 To: ick-discuss@ick.liw.fi Message-ID: <20180703122826.siolafamphg7mpfo@somnambulist.local> References: <20180702152447.GA2363@exolobe3.liw.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180702152447.GA2363@exolobe3.liw.fi> 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-BeenThere: ick-discuss@ick.liw.fi 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: , Sender: ick-discuss-bounces@ick.liw.fi Errors-To: ick-discuss-bounces@ick.liw.fi 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://git.gitano.org.uk/{{ reponame }}.git" ref: "{{ refname }}" path: "{{ reponame }}" - action: git repo: "git://git.gitano.org.uk/{{ reponame }}/debian.git" ref: "{% if debianrefname %}{{ debianrefname }}{% else %}{{ refname }}{% endif %}" path: "{{ reponame }}/debian" - action: git repo: git://git.gitano.org.uk/gp-packaging-tools.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://git.gitano.org.uk/gitano.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, D. -- Daniel Silverstone http://www.digital-scurf.org/ PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69 _______________________________________________ ick-discuss mailing list ick-discuss@ick.liw.fi https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi