Ick as a hosted service: my current goal
by Lars Wirzenius
I've mentioned this on the IRC channel, so I might as well say it on the
mailing list as well: my current mid-term goal for ick is to make it into a
hosted service. I want to have an ick instance that people can use. Some
day I hope that will be useful enough for people to pay to use it. I intend
this to be secrue, safe, and fun to use.
I've updated the roadmap accordingly:
https://ick.liw.fi/roadmap/
Any feedback on that is welcome.
4 years, 7 months
Proposal: an icktool lint subcommand
by Daniel Silverstone
Hi,
I have noticed, over time, that it's possible to get into situations
where the controller is in a bit of an inconsistent or messy state.
To that end I'd like to suggest the introduction of a set of lints which
can be run against the controller to tell you about it (or a subset of it).
Example lints might be:
* Projects refer to pipelines which do not exist
* Projects refer to pipelines but do not have all the requisite parameters
* Pipelines exist which are not referred to by any project
* Pipelines exist with no actions
Some of these lints could be run during make-it-so to report issues before
uploading to the server, others may only make sense once uploaded but could
provide a useful way to diagnose issues. I have hit all of these in my limited
time playing with ick2 so far.
Whether the lints should be icktool side, or server-side and retrieved by
icktool remains to be seen, I'd guess icktool-side to begin with.
What do people think? We can flesh out how the command and output would look
once we know if this is something people would like and what lints people can
think of.
D.
--
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
4 years, 7 months
Making the "git" action in ick more useful
by Lars Wirzenius
The current version of ick has a "git action", which works like this:
* requires the project parameters git_url, git_ref, git_dir
* is run on the host, not in a container, because it uses the host's
(which is a worker) ssh key to access the git server, if access is
via ssh
* if the directory named in git_dir does NOT exist, effecitvely runs
"git clone $git_url $git_dir" (except without shell quoting issues)
* if the git_dir directory DOES exist, runs, in that directory:
"git remote update --prune"
* the above commands do all the network operations; the user is then
expected to run other commands, inside the container, to do anything
else to access the right ref ("git checkout $git_ref" etc)
This design means that only the parts that are absolutely necessary to
run outside the container are done there, and the user has the
flexibility to customise the rest. The goal is for ick to provide a
default "prepare_workspace" pipeline that does all the things that
typical users require, so each user is not forced to reinvent a
triangular wheel, loosely attached.
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.)
Let the Brainst Orming begin. (See description of this product:
https://www.amazon.de/dp/B00UWNJ9OI/)
--
I want to build worthwhile things that might last. --joeyh
4 years, 8 months