What's needed before ick is ready for others to use?
by Lars Wirzenius
This morning I've been pondering on the following question: should I
try to achieve "ready for others to use" as soon as possible, or
should I concentrate on making sure all existing functionality is of
high quality?
The big difference is that the former would hopefully result in
contributions from others sooner, the latter is would hopefully avoid
a deluge of bug reports.
I am leaning towards the former. Perfectionism is good, but it makes
things take a really long time and if things take too long, I get de-
motivated. "Write shit, but fix it quickly."
So what would it take for ick to be ready for others to use? Note that
it doesn't have to be perfect, it needs to work just well enough that
others are able to do at least something useful with it.
Here's my list, and I would appreciate feedback on this. Quick first
reactions are fine, no need to polish and do deep thinking.
* ick builds and publishes its own .deb packages. Presumably
this=C2=A0
would mean others can do the same for their own projects.
* Ick has at least a rudimentary notification system. The current
approach is to run "watch icktool status" and that's not really
good enough. Notification by email would be enough, I think.
* Uses Qvisqve for authentication. The current approach of having
every API client create its own access tokens is silly.
* ick constructs a build graph of all pipelines at the starts of
a=C2=A0
build. This means that it won't be necessary to trigger each
pipeline by hand and opens up a future where executing different
actions concurrently on different workes is a possibility.
* ick can do incremental builds by populating the workspace from=C2=A0
previous build. This means that if one source file changes, it's
no longer necessary to do a full build.
What do you all think? Is there something you can think of that ick
must do before you'd be willing to give it a try?
5 years, 1 month
Notification system for ick
by Lars Wirzenius
I'd welcome feedback on this (text reproduced below):
http://ick.liw.fi/blog/2018/04/04/notifications_in_ick_the_mvp/
Would that be sufficiently useful for your initial needs? Is there
something there you'd be willing to do without?
- - -
Ick will need a way to notify users about build failures. Later on,
the same notification mechanism can be used for other things, but
let's
start with the minimal thing that is useful. Here's a sketch.
*
Notifications will be configured in the project resource in the
controller.
* The controller will trigger a **notification service** to
actually
send the notification. Don't want to burden the controller
with all
the details of how notifications are sent, but the
controller needs
to trigger a notification. (It will do this by
telling a worker to
do it, so that we don't need to have the
controller do blocking HTTP
calls to other services.)
* Notifications
will be triggered only on failures. Later on, this
needs to be
configurable and include options like a "build now
succeeds, when it
previously failed", and possibly also "always
notify".
* Later on, ick
needs to be able to flexibly notify via a number of
channels: email,
IRC, Matrix, SMS, RSS/Atom, etc. Probably also
proprietary systems
like Slack will need to be supported. However,
we'll start with just
email.
* The notification emails will always be sent with the same
sender
information, and this will be configured by the sysadmin.
Also, it
will always be sent with the same mail server, also
configured by
the sysadmin. Probably using `/usr/sbin/sendmail`
rather than SMTP.
Aiming for minimal necessary configuration to start
with.
* The template for the emails will be hard-coded in the source
code
(for now).
The mails will containt the following information:
*
name of project that was built
* build number
* build id
* log id (for
use with icktool)
* last 1000 lines of build log
* exit code of build
Lat
er on, this will need to extended, but the above should suffice for
now
.
5 years, 1 month
The project uses python3, right?
by Steve Kemp
The top-level `README` says:
"Ick2 is written in Python 2 (do not ask for Python 3, it will
happen when it happens)."
However the generated package uses python3 in all the dependencies,
as you can see in `debian/control`.
That makes me think that the README section is outdated/mistaken.
Steve
--
https://www.steve.org.uk/
5 years, 2 months
Trivial typo ..
by Steve Kemp
The file `INSTALL` contains the typo `passowrd`.
Steve
--
5 years, 2 months
