ubuntu-docker-images team mailing list archive

[Sergio Durigan Junior <sergio.durigan@xxxxxxxxxxxxx>]

On Monday, June 14 2021, Bryce Harrington wrote:

> Given that the software in the images should in theory change super
> infrequently, then a longer interval between test auto-runs makes
> sense.  If a given image really only changes no more than once a month,
> then having 30 days of test runes isn't going to add a lot of value.
> So I'd look at even maybe just once a week.

Yeah.  Our workflow is somewhat peculiar: these images stay a long time
untouched, but then we have bursts of activity when we rebuild them
every few days, for example.

> As long as there's a manual way to trigger tests to run, e.g. at upload
> time or after a new base image change has been released, then can just
> include a retrigger step as part of the upload+review process.  That'd
> be the ideal context to deal with test failures, and my guess is going
> to detect 95% of the actual problems the oci images would hit in
> practice.

I think Jenkins has a REST API, so it should be possible to code
something up in our scripts and make them automatically trigger tests
after (e.g.) the retagging has been done.  The only "problem" here is
that our Jenkins instance lives behind the VPN, so the user would have
to either connect automatically to it or check the connection before
retriggering the tests.

The other problem with putting this logic inside our scripts is that, as
we know, they will eventually be retired in favour of other tooling.
That's why I think that implementing something that will run on Jenkins
will be more future-proof.

Thanks,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14