[discourse-web/gnome] Add CI

[Bartłomiej Piotrowski <bpiotrowski src gnome org>]

commit 20b362ec545a4a71c6199bd06794db7ddb7dc73c
Author: Bartłomiej Piotrowski <bpiotrowski gnome org>
Date:   Wed Apr 6 14:34:58 2022 +0200

    Add CI

 .gitlab-ci.yml | 182 +++++----------------------------------------------------
 1 file changed, 14 insertions(+), 168 deletions(-)
---
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 31d99be..edf0f05 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,169 +1,15 @@
-### This GitLab-CI scipt provides a template to publish an OpenShift resource (a Docker image and/or a 
template)
-### shared with other users.
-###
-### Requirements:
-###   1. An `externally managed resource` must be created before you can push the image to OpenShift.
-###      This step must be done by OpenShift admins, so contact them before anything else.
-###   2. After step 1, you will receive the credentials of a service account with rights to publish a image 
and update
-###      a template with name '$RESOURCE'.
-###   3. Adapt this .gitlab-ci.yml definition to match your deployment. In most cases, only the `variables` 
section needs
-###      to be adapted
-###
-### In this template, we use three different environments to represent the status of the Continuous 
integration build.
-###   1. `dev` represents development on a custom git branch. Once there is something new pushed to a custom 
branch
-###       The CI build will create a new Image, store it in the GitLab registry with tag `latest`, import it 
to openshift-dev
-###       and run some tests on it.
-###       The template can be deployed to the development cluster (i.e. openshift-dev.cern.ch) with a manual 
trigger
-###       so it can be tested.
-###   2. `staging` represents deployment to the development OpenShift cluster (i.e. openshift-dev.cern.ch).
-###       This environment runs when something is pushed with a tag and tries to replicate a deployment
-###       to production. The image gets built and pushed to the GitLab registry using the git tag as the 
Docker tag.
-###       Whenever this happens, the template is automatically updated and a manual trigger
-###       is enabled to tag the image as `stable`, all of this in the development cluster (i.e. 
openshift-dev.cern.ch).
-###       NOTE: tagging the image as `stable` will trigger a re-deploy of all the applications using it in
-###       `openshift-dev.cern.ch`, so do it with care!
-###   3. `production` represents deployed to the production OpenShift cluster (i.e. openshift.cern.ch).
-###       This environment also runs when a change is pushed with a tag to master. The template is 
automatically
-###       updated on production (e.g `openshift.cern.ch`) but the image requires a manual trigger before
-###       it is tagged as `stable`.
-###       NOTE: tagging the image as `stable` will trigger a re-deploy of all the applications
-###       using it in `openshift.cern.ch`, so do it with care!
-###
-
-variables:
-  ### Disable cache in Docker builds, as this has occasionally resulted in images not containing what was
-  ### expected multiple MRs where being built/retried.
-  NO_CACHE: 'true'
-  ### Replace RESOURCE with the name of the image you want to build and publish in OpenShift
-  ### Important! In order for this template to work, the name of the gitlab repo must match
-  ### also the variable name
-  RESOURCE: discourse-cern
-  ###
-  ### You shouldn't change the following variables
-  NAMESPACE: openshift
-  OPENSHIFT_SERVER: https://openshift-dev.cern.ch
-
-### By default, there are 6 stages that we may use:
-### Feel free to adapt this to your specific case.
-stages:
-  - build
-  - tag_image
-  - import_image # This stage is only used when the built image is stored in the GitLab Registry
-  - update_template
-  - deploy
-
-### 'Build' stage
-### Build the image and store it in the registry. It is important that this step
-### doesn't override the image the applications are running, as we haven't tested the image yet
-### The build will be tagged with latest whenever we push to any branch except in the case
-### where we push a tag
-build_dev_version:
+discourse:
   stage: build
-  except:
-    - tags
-  environment: dev
-  tags:
-    - docker-image-build
-  script: 'echo "Building Docker image..."'
-
-### When building tags, use the git tag as the docker tag of the image
-build_tagged_version:
-  stage: build
-  only:
-    - tags
-  tags:
-    - docker-image-build
-  script: 'echo "Building Docker image..."'
-  variables:
-    TO: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}
-
-### If a new tag is pushed it needs to be referenced into the imagestream
-tag_image_dev: &tag_image
-  stage: tag_image
-  environment: staging
-  image: gitlab-registry.cern.ch/paas-tools/openshift-client:v3.10.0
-  script:
-    - oc tag --source=docker ${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG:-latest} 
${RESOURCE}:${CI_COMMIT_TAG:-latest} --reference-policy=local --token=${TOKEN} --server=${OPENSHIFT_SERVER} 
-n ${NAMESPACE}
-  variables:
-    TOKEN: ${SERVICE_ACCOUNT_TOKEN_DEV}
-
-tag_image_prod:
-  <<: *tag_image
-  variables:
-    OPENSHIFT_SERVER: https://openshift.cern.ch
-    TOKEN: ${SERVICE_ACCOUNT_TOKEN_PROD}
-
-### 'update_template' stage
-### Uploads a new version of the template to OpenShift.
-### For development purposes, there is a manual trigger than allows to publish a new
-### template to the development cluster (i.e openshift-dev.cern.ch) even if building
-### the image fails
-update_template_dev:
-  stage: update_template
-  environment: dev
-  when: manual
-  image: gitlab-registry.cern.ch/paas-tools/openshift-client:v3.10.0
-  script:
-    - oc replace template --token=${TOKEN} --server=${OPENSHIFT_SERVER} -n ${NAMESPACE} -f 
templates/${RESOURCE}.yaml
-  variables:
-    TOKEN: ${SERVICE_ACCOUNT_TOKEN_DEV}
-
-update_template_staging:
-  stage: update_template
-  environment: staging
-  only:
-  - tags
-  when: always # This will allow us to deploy the template even if building the image fails
-  image: gitlab-registry.cern.ch/paas-tools/openshift-client:v3.10.0
-  script:
-    - oc replace template --token=${TOKEN} --server=${OPENSHIFT_SERVER} -n ${NAMESPACE} -f 
templates/${RESOURCE}.yaml
-  variables:
-    TOKEN: ${SERVICE_ACCOUNT_TOKEN_DEV}
-
-update_template_production:
-  stage: update_template
-  environment: production
-  only:
-  - tags
-  when: manual
-  image: gitlab-registry.cern.ch/paas-tools/openshift-client:v3.10.0
-  script:
-    - oc replace template --token=${TOKEN} --server=${OPENSHIFT_SERVER} -n ${NAMESPACE} -f 
templates/${RESOURCE}.yaml
-  variables:
-    OPENSHIFT_SERVER: https://openshift.cern.ch
-    TOKEN: ${SERVICE_ACCOUNT_TOKEN_PROD}
-
-### 'Deploy' stage
-### Publish the image with tag `stable`. NOTE: this will re-deploy all the applications using
-### the `stable` tag (by default, all of them) so do it with care. In the `production` environment,
-### taggig with `stable` requires launching a manual trigger
-deploy_staging:
-  stage: deploy
-  environment: staging
-  only:
-  - tags
-  when: manual
-  image: gitlab-registry.cern.ch/paas-tools/openshift-client:v3.10.0
-  script:
-    - oc --token=${TOKEN} --server=${OPENSHIFT_SERVER} -n ${NAMESPACE} tag ${RESOURCE}:${CI_COMMIT_TAG} 
${RESOURCE}:stable
-  variables:
-    OPENSHIFT_SERVER: https://openshift-dev.cern.ch
-    TOKEN: ${SERVICE_ACCOUNT_TOKEN_DEV}
-    GIT_STRATEGY: none
-
-deploy_production:
-  stage: deploy
-  environment: production
-  only:
-  - tags
-  when: manual
-  image: gitlab-registry.cern.ch/paas-tools/openshift-client:v3.10.0
-  script:
-    - oc --token=${TOKEN} --server=${OPENSHIFT_SERVER} -n ${NAMESPACE} tag ${RESOURCE}:${CI_COMMIT_TAG} 
${RESOURCE}:stable
-  variables:
-    OPENSHIFT_SERVER: https://openshift.cern.ch
-    TOKEN: ${SERVICE_ACCOUNT_TOKEN_PROD}
-    GIT_STRATEGY: none
-
-
-
+  image:
+    name: quay.io/gnome_infrastructure/buildah:latest
+  rules:
+    - changes:
+      - "*"
+  script:
+    - base_image_tag="$(curl -s https://raw.githubusercontent.com/discourse/discourse_docker/main/launcher | 
grep '^image="discourse/base:.*"$' | cut -d'"' -f2 | cut -d: -f2)"
+    - buildah bud -t ${OCI_REGISTRY}/gnome_infrastructure/${CI_JOB_NAME}:latest -f Dockerfile --build-arg 
BASE_IMAGE_TAG=$base_image_tag .
+    - >-
+      if [ "$CI_COMMIT_REF_PROTECTED" == "true" ]; then
+        buildah login -u ${OCI_REGISTRY_USER} -p ${OCI_REGISTRY_PASSWORD} ${OCI_REGISTRY}
+        buildah push ${OCI_REGISTRY}/gnome_infrastructure/${CI_JOB_NAME}:latest
+      fi