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
This is needed because `GITLAB_VERSION` has a special meaning in
`omnibus-gitlab` triggers: this is the GitLab version to build.
The problem is that `omnibus-gitlab` also has triggers to run QA for an
`omnibus-gitlab` commit, and if we use `GITLAB_VERSION` in that case,
the comment would be posted on the GitLab CE/EE commit (stored in
`GITLAB_VERSION`), whci hwouldn't make any sense.
Thus we need `TOP_UPSTREAM_SOURCE_SHA` to represent the commit on
which we want to leave a comment.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Cleanup code, and refactor tests that still use Rugged. After this, there should
be no Rugged code that access the instance's repositories on non-test
environments. There is still some rugged code for other tasks like the
repository import task, but since it doesn't access any repository storage path
it can stay.
- 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>
When on a tag, trigger a multi-project pipeline in the CNG repostiory.
Opting for a trigger rather than an addition to our release-tools
project for a few reasons:
- The Dockerfiles in the CNG image repo change infrequently, and as a result
I don't feel the need/overhead for stable branches in that repo at this time
- My intent with the CNG repo, is that once stable, the Dockerfiles
would actualy move to their component projects, to be versioned with the
code they are building
- It is likely that we will want to followup with a manually triggered package
for branches for devs, and possibly review apps, so it made sense to
build the CNG ci jobs to accept this sort of pipeline.