Learn all about how to update your OpenDevStack repositories and the running installation of it.
Updating repositories means that new refs from repositories under
github.com/opendevstack are pushed into the repositories in your BitBucket
instance. Note that only updates to the
production branch in BitBucket will
have any effect on the OpenDevStack installation.
First, you need a clone of each repository in BitBucket which should be updated on your local machine.
Once this has been done, you need to fetch new refs from
github.com/opendevstack. To do so, add a remote pointing to it like this:
git remote add ods https://github.com/opendevstack/<REPO_NAME>.git
Now you are ready to update the refs. It is recommended to update both the
master branch and, unless you want to live off the bleeding edge, a release
branch such as
1.0.x. Use the steps shown below:
# Ensure you have the latest refs from ODS locally git fetch ods # Update master git checkout master git reset --hard ods/master git push origin master # Update 1.0.x git checkout 1.0.x git reset --hard ods/1.0.x git push origin 1.0.x
So far, your OpenDevStack installation has not been affected yet because the
production branch has not been updated yet. To do that, it is recommended to
create a pull request on BitBucket from
production This serves
as a gate to control changes coming in, and spread knowledge about what has
Now that changes are “live”, you need to update (parts of) the installation.
Updating consists of two parts: following the general update procedure (applicable to all version updates) and a version specific update procedure.
Before proceeding, it is advisable to make a backup of the existing OpenShift configuration. This can be done easily with Tailor:
# backup CD project tailor export -n cd > backup_CD.yml # backup provision app projects tailor export -n prov-cd > backup_PROV_CD.yml tailor export -n prov-dev > backup_PROV_DEV.yml tailor export -n prov-test > backup_PROV_TEST.yml
Note that the executing user needs to have permissions to access all resources
cd namespaces for this to work properly.
Next, update Tailor to the version corresponding to your new OpenDevStack version. At the moment, this version is noted at the start of each version specific update procedure.
Then, update the configuration parameters (located in
according to what has changed in the
Once configuration is up-to-date, the OpenShift templates stored within OpenShift need to be updated:
# Within your local "ods-project-quickstarters" repository cd ocp-templates/scripts ./upload-templates.sh
tailor update in all
ocp-config folders to bring OCP resources (such
as DC or BC) into sync. Review the diff produced by Tailor carefully, especially around
changes to PVCs. To find each
ocp-config folder, you can use e.g.
find . -name ocp-config -not -path "./ods-configuration*" on Unix.
After all OCP resources have been updated, you need to start a build for all build configs
cd namespace to create new images.
Also, the provisioning app should be updated. To do that, run
ocp-config folder, and then trigger a build in Jenkins to redeploy the
Finally, push the vanilla branch or tag of the shared library to your
BitBucket instance. E.g. if your
production branch is based on
firstname.lastname@example.org. All quickstarters in the
1.0.x branch point to this Git
reference in the
Jenkinsfile. It is not recommended to point to
production in your quickstarters,
otherwise consumers will encounter failing builds when breaking changes are introduced in the
production branch. You may also choose to create a custom tag from your
production branch and
Jenkinsfiles point to this tag.
Now that the general procedure has been completed, you need to apply all the update notes below which apply to your version change.
1.0.x requires Tailor 0.9.3.
There is a new webhook proxy now, which proxies webhooks sent from BitBucket to Jenkins. As well as proxying, this service creates and deletes pipelines on the fly, allowing to have one pipeline per branch. To update:
cdproject by running
oc process cd//cd-jenkins-webhook-proxy | oc create -f- -n xyz-cd. Repeat for each project.
For each component, follow the following steps:
verbose: trueconfig (replace with
debug: trueif you want debug output).
branchToEnvironmentMapping, see README.md. If you used environment cloning, also apply the instructions for that.
Adapt the content to match the latest state of the quickstarter boilerplates.
In BitBucket, remove the existing “Post Webhooks” and create a new “Webhook”,
pointing to the new webhook proxy. The URL has to be of the form
events, select “Repository Push” and “Pull request Merged + Declined”.
If you want to build the provisioning app automatically when commits are pushed to BitBucket, add a webhook as described in the previous section.
1.0.x makes use of the
BUILD_URL env variable automatically set by Jenkins. This
env variable might be
null in your Jenkins master. To fix this, copy
https://github.com/opendevstack/ods-core/blob/1.0.x/jenkins/master/configuration/init.groovy.d/url.groovy into each Jenins master to