-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Optionally) Deploy via Tailor #96
Comments
This was referenced Jul 12, 2019
@clemensutschig @michaelsauter moving this to 2.0 |
@gerardcl Yes, definitely. |
Moving this to 3 as it is not pressing and part of the implementation depends on what MRO expects from a quickstarter, which is not defined yet. Apart from that, we already merged a good part of this change which improves the "normal deployment". |
michaelsauter
pushed a commit
to BIX-Digital/ods-jenkins-shared-library
that referenced
this issue
Apr 27, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In order to manage all OpenShift resources via code, the Jenkins pipeline must be able to read configuration from the repository, and apply any changes necessary to bring the current cluster into the desired state.
Here's how it works in detail:
When no
openshift
folder is present, a deployment is just an update of thecontainer image.
However, when an
openshift
folder is present, this stage can fully control theOpenShift resources for this service via code, e.g. it can deploy changes to
environment variable, or changing constraints etc. of the DeploymentConfig. It
does this by using Tailor (https://github.com/opendevstack/tailor) to sync the
"desired state" expressed in templates and parameters with the "current state"
found in OpenShift. Tailor automatically calculates the required changes and
applies them as one atomic JSON patchset.
The "tailor" binary is pre-installed in the slave-base. The behaviour of Tailor
can be customized by adding a "Tailorfile" (or a more specific, per-project
version of it such as "Tailorfile.foo-dev" and "Tailorfile.foo-test").
The actual rollout of the deployment is triggered explicitly via "oc rollout",
which also allows us to monitor the progress and fail the build if the rollout
does not work. Note that any automatic deployment triggers are disabled to
achieve this. Also, the image being rolled out is not tagged with "latest" - the
stage simply deploys the image tag that was built in the previous stage. This
assumes that the template processed by Tailor consumes the "TAGVERSION" param
and that the template uses it correctly to set the image.
This addresses #59 and #67.
The text was updated successfully, but these errors were encountered: