The function that retrieves the dependable job is pretty basic and
retrieves the first job found with the matching name, but this job can
be failed but then successfully retried. In that case, we would exit the
depending job even though the dependable job actually succeeded (the
second time). Let's simplify things, be optimistic and continue with the
depending job even if the dependable job fails.
That reverts to the original behavior.
Signed-off-by: Rémy Coutable <remy@rymai.me>
If a script is waiting for a job to be done and that job fails,
exit with an error status so that the script doesn't continue
with a prerequisite in an invalid state.
In `deploy`, if the previous deployment failed, we delete/cleanup all
the objects related to the release, including secrets. The problem is
that if we create the root password before that, it will be then
recreated during the deploy with a random value!
By creatigng the secret just before actually deplying a new release, we
ensure that it won't be overriden.
Signed-off-by: Rémy Coutable <remy@rymai.me>
* Uses the same supporting code as used in EE
* Includes automated cleanup
* Install external-dns helm chart to review apps cluster if it isn't
already
* Adds variables REVIEW_APPS_AWS_SECRET_KEY and
REVIEW_APPS_AWS_ACCESS_key
* review-apps-ce uses a different cipher
- Stop review app's environment after 2 days
- Delete review app's environment after 3 days
- Delete Helm release after 4 days
Signed-off-by: Rémy Coutable <remy@rymai.me>
