4.6. Integrating With Other CI Tools

When to Read This Chapter

• When you want to keep using the CI tool you already have and deploy to COP
• When you have decided on GitLab CI, GitHub Actions, or similar instead of Jenkins
• When a standard CI tool is mandated internally and cannot be changed

What a CI Tool Is

CI (Continuous Integration) is the practice of building and checking automatically whenever source changes. A CI tool is the program that does that for you; Jenkins, GitLab CI, GitHub Actions, and Tekton are examples.

Configuration file formats and screens differ by tool, but what they do is the same. When a defined condition is met (the source changes, a time arrives, a person selects a button), they run defined commands in order.

Why the Tool Can Be Swapped

COP's build and deployment consists of five shell scripts (see 4.5). The CI tool merely calls them.

The same is true of the Jenkins Jobs COP provides by default. What the build Job actually contains is all of this.

cd <install path>/workspaces/apps/<namespace>/<app name>
./build-app.sh
./build-push.sh

The deploy Job is one line, ./build-deploy.sh, and the rollback Job is one line, ./build-rollback.sh. Nothing depends on Jenkins syntax or plugins. Any tool that can run shell commands produces the same result.

Put another way, when replacing the CI tool, the only thing to recreate is a single pipeline definition file; the build and deployment logic stays as it is.

The Scripts Used for Integration

Script	What it does	CI stage
build-app.sh	Downloads the source and creates an image with S2I	build
build-push.sh	Pushes the image to the registry	build
build-deploy.sh	Swaps the cluster Deployment's image and waits for completion	deploy
build-history.sh	Prints the deployment history	verification
build-rollback.sh	Reverts to the previous deployment	failure handling

The detailed behavior of each script is in 4.5.

What the Tool Has to Do

There are only three things to prepare on the CI tool side.

Task	Description
Define the trigger	On push to the source repository, at a set time, or when a person selects it
Change to the working directory	The scripts call each other by relative path, so they must run in that directory
Run the scripts in order	Build, push, deploy. Stop if an earlier stage fails

Make sure it does not proceed after an earlier stage fails. If the deployment runs after a failed build, the previous image is deployed and it ends as "deployment succeeded" with your changes not applied. Most CI tools stop at the point where a command exits with a non-zero value.

Configuration Examples by Tool

The same work is written like this in each tool. Change the paths and names to match your installation.

GitLab CI (.gitlab-ci.yml)

stages: [build, deploy]

variables:
  APP_DIR: /openmaru/workspaces/apps/egov/egov

build:
  stage: build
  script:
    - cd $APP_DIR
    - ./build-app.sh
    - ./build-push.sh

deploy:
  stage: deploy
  script:
    - cd $APP_DIR
    - ./build-deploy.sh

GitHub Actions (.github/workflows/deploy.yml)

on: [push]

jobs:
  build-deploy:
    runs-on: self-hosted
    env:
      APP_DIR: /openmaru/workspaces/apps/egov/egov
    steps:
      - run: cd $APP_DIR && ./build-app.sh && ./build-push.sh
      - run: cd $APP_DIR && ./build-deploy.sh

Jenkins pipeline (Jenkinsfile)

pipeline {
  agent any
  environment { APP_DIR = '/openmaru/workspaces/apps/egov/egov' }
  stages {
    stage('Build')  { steps { sh 'cd $APP_DIR && ./build-app.sh && ./build-push.sh' } }
    stage('Deploy') { steps { sh 'cd $APP_DIR && ./build-deploy.sh' } }
  }
}

The Jenkins Jobs COP provides by default are Freestyle jobs, not pipelines, so the same commands sit in the "Build Steps > Execute shell" box on the configuration screen (see 4.4).

Two Places to Run

Where the scripts run matters.

Method	Description	What it needs
Running on the Bastion	The CI tool connects to the Bastion and issues commands	Bastion access (SSH) or an agent installed on the Bastion
Running in a container	The CI tool starts a container and runs them inside it	An image containing S2I, container tooling, and kubectl, plus cluster credentials

Running on the Bastion is simpler. The required tools and credentials are already in place, so there is nothing extra to prepare. This is especially true in an air-gapped environment — the container method requires building a build image and bringing it in separately.

What to Prepare

Whichever tool you use, the following must be in place.

Item	Description
Source repository access	It must be able to download the source to build
Registry account	Permission to push images. build-env.sh holds it
Cluster credentials	Permission to edit Deployments in the target namespace (see 7.1)
Library repository	In an air-gapped environment it uses the internal repository. env.sh holds it

Grant only as much cluster permission as needed. What deployment needs is permission to read and edit Deployments in that namespace. Giving a CI tool cluster-wide administrator permission means the whole cluster is breached along with the tool.

How to Verify

Even after changing CI tools, the places to check the result are the same.

What to check	Where
Whether the new image was deployed	The image tag on the Deployment detail in the Console (see 3.2)
Whether pods started normally	The pod list in the Console (see 3.1)
Whether the deployment history was recorded	Deployment History on the Deployment detail (see 3.2)
What went wrong	Pod logs and events (see 3.1)

The image tag is recorded in the deployment history as it is. Because the tag has the form <Git tag>-<first 7 characters of the commit>, you can tell which commit was deployed from the Console screen alone.

Cautions

• Do not deploy the same application from two tools at once. Whichever finishes later wins. If you are migrating, stop one of them first.
• Do not pin the image tag to latest. The deployment history holds only the same value, so revisions cannot be told apart, and reverting fetches the same image again.
• Do not copy the scripts into the CI configuration file. They would have to be copied again with every tool change, and the contents would drift apart between tools until the results diverge. If something needs fixing, fix the script.
• In an air-gapped environment, the CI tool cannot reach the internet. If the tool downloads anything from the internet during installation, that part has to be redirected to an internal repository.