How do you develop a custom plugin for Gitlab CICD?

codependent 0
Viewed 25

I need to integrate a Gitlab CICD pipeline with a custom Delivery Manager Tool. My pipeline will need to invoke the delivery manager API with some info.

In Jenkins we developed a plugin that provided a pipeline step - void deployEnv (String app, String environment ) - that can be used in the different stages, e.g.:

   deployEnv("applicationx", "production")

Is there a way to develop a similar plugin in Gitlab CICD?

Is it possible to invoke a remote URL from a Gitlab CICD pipeline passing some credentials?

gitlab gitlab-ci
1 Answers

The closest analog for this kind of "plugin" in GitLab CI is probably a CI templated job definition. There's maybe a few ways to formulate this. There are a number of methods for abstracting and including job definitions provided by others. Some of the basic tools are: include:, extends:, !reference, "hidden job" keys, and YAML anchors.

Providing reusable templates

If you just need to provide an abstraction for a series of steps, a "hidden key" definition would be the closest to what you want.

Consider the following template YAML. This might be embedded directly in your .gitlab-ci.yml file(s) or you might choose to include it any number of configurations from a remote location using the include: keyword.

In this fictional example, we provide a script step that expects two environment variables to be present: APPLICATION_NAME and DEPLOYMENT_ENV. These variables are used (in this fictional example) to call a remote API passing those values as path parameters. Here, the definitions are provided in a "hidden job" key

.deploy_to_env:
  image: curlimages/curl  # or otherwise have `curl` in your environment
  script:
    - |
      if [[ -z "$APPLICATION_NAME" || -z "$DEPLOYMENT_ENV" ]]; then
          echo "FATAL: you must set APPLICATION_NAME and DEPLOYMENT_ENV variables"
          exit 1
      fi          
    - curl -XPOST "https://my-deployment-api.example.com/${APPLICAITON_NAME}/${DEPLOYMENT_ENV}"

Let's assume this yaml file exists in a file named deploy.yml in a project whose path is my-org/templates.

Using templates

Now let's say a pipeline configuration wants to leverage the above definition to deploy an application named applicationx to production.

First, in any case, the project should include: the remote definition (unless you choose to embed it directly -- e.g., copy/paste).

include:
  - project: my-org/templates
    file: deploy.yml
    ref: main # or any git ref, or omit to use default branch

Then you can use the extends: keyword to form a concrete job from the hidden key.

deploy_production:
  stage: deploy
  extends: .deploy_to_env
  variables:
    APPLICATION_NAME: "applicationx"
    DEPLOYMENT_ENV: "production"

Or, if you want to embed the deployment steps in the middle of other script steps using !reference is useful here.

deploy_production:
  stage: deploy
  script:
    - export APPLICATION_NAME="applicationx"
    - export DEPLOY_ENV="production"
    # these could also be set in `variables:`

    - echo "calling deployment API to deploy ${APPLICATION_NAME} to ${DEPLOY_ENV}"
    - !reference [.deploy_to_env, script]
    - echo "done"

There's a lot of ways to handle this, these are just two examples.

sytech0
Related