Hi,
> cool! Do you have an idea of how we could
automatically update our
> jobs based from this?
A job that triggers on gerrit post-merge events (osmo-ci) would be my
preferred choice. It's more elegant than polling and every merged
change will be applied in seconds/minutes. Moreover, this job could
also trigger "update-osmo-ci-on-slaves" job as suggested by Max if a
change in the scripts/ folder has been introduced.
Another topic to discuss are the credentials. The JJB allows to
declare them in a file or pass them while invoking job creation. Would
it be "okay" to store them on node(s)? Another way is to declare
credentials in Jenkins global configuration and use the 'mask password
plugin' to no show them in the console log. Furthermore, a dedicated
user with precise permission to deploy jobs is preferrable.
What is your opinion?
> Not on purpose but depends on when we created the
job?
Max already commented on gerrit that this is probably time related and
that the "latest and greatest" version should be used everywhere.
> I don't think we want to verify drafts, we
rarely use them anyway
Okay, then 'draft verification' will be removed from the YAML file.
> On purpose. E.g. when executing tests that listen
on a UDP/TCP/SCTP
> port we can't run them concurrently unless the ports are randomized
> or somehow virtualize them. In the case of concurrent builds we know
> we either don't run system tests or we run them in docker.
Ah true, then the current YAML should be sufficient as it allows each
job to define whether concurrent builds are allowed (default: false).