canonical-ci-engineering team mailing list archive

[Vincent Ladeuil <vila+ci@xxxxxxxxxxxxx>]

>>>>> Francis Ginther <francis.ginther@xxxxxxxxxxxxx> writes:

    > I've created a simple job to facilitate deployment of cu2d job updates:
    > http://q-jenkins.ubuntu-ci:8080/job/deploy-cu2d-stack/

    > This does provide a 'safe' deployment as you still need to ensure that
    > no jobs are running for the stack being updated.

Great !

I know you guys have been deploying from home but if we could all agree
to use only this job instead, it will allow us (ci) to setup a simpler
process for the q-jenkins recovery plan.

Concretely, there are many places in cu2d that refers to $JENKINS_HOME
or ~jenkins as /iSCSI/jenkins. This forbids changing ~jenkins on
q-jenkins without changing all the places that refers to that value. And
as long as those scripts are deployed from home they *cannot* know what
~jenkins expands to.

So by deploying *only* from q-jenkins itself, we remove that constraint
and can fix all references.

So that job is only the first step :)

We have a backup to /var/lib/jenkins_local but as explained above, that
cannot be used to switch ~jenkins and restart the server, all the
references would point to the wrong place.

So while not perfect, removing the constraint that ~jenkins have to be
guessed will make things simpler.

And since there have been some network issues while deploying jobs,
doing so on the server itself should also address them as a side-effect.

@Francis: If I'm reading that job correctly 'stacks/*/*.cfg' will work
as a value for the 'stacks' parameter and will deploy all stacks.

If that's correct can we use that as the default value ?

Also, can we make that job part of cu2d-config itself ? If only to not have to
think too much about where we need to archive it otherwise ;)

      Vincent