Setup

Webhook Server

Using scm-engine as a webhook server allows for richer feature set compared to GitLab CI pipeline mode

• Real-time reactions to changes.
• Reacting to comments.
• Access to webhook event data in scripts via webhook_event.* (see server docs for more information).
• A single scm-engine instance (and single token) for your GitLab project, group, or instance depending on where you configure the webhook.
• Each Project still have their own .scm-engine.yml file, it's downloaded via the API when the server is processing a webhook event.
• A single "bot" identity across your projects.
• Turn key once configured; if a project want to use scm-engine they just need to create the .scm-engine.yml file in their project.
• No intuitive access to evaluation logs within GitLab (you can see them in the server logs or in the webhook failure log).

Setup:

1. Deploy scm-engine within your infrastructure in an environment that can communicate egress/ingress with GitLab. (see server)
2. Configure your webhook at Project, Group, or Server level to hit the /gitlab endpoint on the scm-engine server endpoint. (see server)

GitLab-CI pipeline

Using scm-engine within a GitLab CI pipeline is straight forward - every time a CI pipeline runs, scm-engine will evaluate the Merge Request.

• Simple & quick installation.
• Limited access token permissions.
• Easy access to evaluation logs within the GitLab CI job.
• Can't react to comments; only works within a CI pipeline.
• Higher latency for reacting to changes depending on how fast CI jobs run (and where in the pipeline it runs).

Setup:

1. Add a .scm-engine.yml file in the root of your project.
2. Create a CI/CD Variable
   1. Name must be SCM_ENGINE_TOKEN
   2. Value must a Project Access Token
      1. Must have api scope.
      2. Must have developer or maintainer role access so it can edit Merge Requests.
   3. Mask should be checked.
   4. Protected should NOT be checked.
   5. Expand variable reference should NOT be checked.

3. Setup a CI job using the scm-engine Docker image that will run when a pipeline is created from a Merge Request Event.

   scm-engine::evaluate::on-merge-request-event:
     image: ghcr.io/jippi/scm-engine:latest
     rules:
       - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
     script:
       - scm-engine evaluate
   
   scm-engine::evaluate::on-schedule:
     image: ghcr.io/jippi/scm-engine:latest
     rules:
       - if: $CI_PIPELINE_SOURCE == "schedule"
     script:
       - scm-engine evaluate all
   

4. Done! Every Merge Request change should now re-run scm-engine and apply your label rules