GitLab#

Overview#

The GitLab application enables Nokia EDA to integrate with GitLab to support the following scenarios:

• Create GitLab issues or run GitLab pipelines based on the triggering events from EDA (alarms or queries).
• Create GitLab issues or run GitLab pipelines using the workflow definition resources provided by the application.

The app provides these resource groups:

• GitlabInstance and ClusterGitlabInstance: define how to connect to GitLab
• GitlabIssue and ClusterGitlabIssue: create and optionally close GitLab issues based on alarms or query events
• GitlabPipeline and ClusterGitlabPipeline: trigger GitLab pipelines based on alarms or query events
• CreateGitlabIssue and RunGitlabPipeline: run-to-completion workflow resources

Installation#

You can install the GitLab app via EDA Store or by running an AppInstaller workflow with kubectl or edactl:

apiVersion: appstore.eda.nokia.com/v1
kind: AppInstaller
metadata:
  name: gitlab-install
  namespace: eda-system
spec:
  operation: install
  apps:
    - appId: gitlab.eda.nokia.com
      catalog: eda-catalog-builtin-apps
      version:
        type: alias
        value: latest

cat << 'EOF' | kubectl apply -f -
apiVersion: appstore.eda.nokia.com/v1
kind: AppInstaller
metadata:
  name: gitlab-install
  namespace: eda-system
spec:
  operation: install
  apps:
    - appId: gitlab.eda.nokia.com
      catalog: eda-catalog-builtin-apps
      version:
        type: alias
        value: latest

EOF

Configuration Notes#

The current deployment template does not expose install-time appSettings.

The following controls the deployment in the EDA base namespace:

• proxy environment variables are read from the fixed ConfigMap name proxy-config
• container limits are fixed at 1 CPU and 1Gi memory

The default requests are fixed at 500m CPU and 500Mi memory.

Getting Started#

Create a GitLab instance first, then reference it from the GitlabIssue or GitlabPipeline resources.

Namespace rules:

• GitlabInstance, GitlabIssue, and GitlabPipeline are namespace-scoped and are typically created in a user namespace such as eda
• ClusterGitlabInstance, ClusterGitlabIssue, and ClusterGitlabPipeline are namespaced CRs, but are intended for use from the EDA base namespace

GitLab Instances#

A GitLab instance defines the target API endpoint and authentication token.

Notable specification fields:

• apiBaseURL: optional base URL. If omitted, the runtime defaults to https://gitlab.com
• authSecretRef.name: Secret name containing credentials (Personal Access Token)
• authSecretRef.key: validated by the API and typically set to token

Credential behavior:

• the runtime reads data.token from the referenced Secret
• it also accepts username and password, but PAT-based authentication is the most common authentication method
• the same Secret may also contain tls.crt, tls.key, and optional ca.crt for TLS client configuration
• for self-managed GitLab, set apiBaseURL to your GitLab API base URL

The resource status contains the fields related to the connectivity parameters of this instance:

• connected: indicates if the instance is connected to GitLab
• error: contains the error message if the instance is not connected
• lastChecked: the last time the instance was checked

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-secret
  namespace: eda
type: Opaque
stringData:
  token: glpat-exampleTokenValue
---
apiVersion: gitlab.eda.nokia.com/v1alpha1
kind: GitlabInstance
metadata:
  name: gitlab-server
  namespace: eda
spec:
  apiBaseURL: https://gitlab.example.com
  authSecretRef:
    name: gitlab-secret
    key: token

cat << 'EOF' | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: gitlab-secret
  namespace: eda
type: Opaque
stringData:
  token: glpat-exampleTokenValue
---
apiVersion: gitlab.eda.nokia.com/v1alpha1
kind: GitlabInstance
metadata:
  name: gitlab-server
  namespace: eda
spec:
  apiBaseURL: https://gitlab.example.com
  authSecretRef:
    name: gitlab-secret
    key: token

EOF

GitLab Issues#

Use GitlabIssue or ClusterGitlabIssue to create issues in GitLab when an alarm or query event occurs.

Notable specification fields:

• trigger.alarm: create a GitLab issue when the matching alarm types occur
• trigger.query: create a GitLab issue when the matching query updates occur
• repo: GitLab project path, typically in group/project form
• instance: referenced instance resource
• closeOnResolve: close the GitLab issue when the alarm clears or the query object disappears
• issue.title and issue.body: Go templates rendered with the triggering event data
• issue.assignees, issue.labels, issue.milestone: optional GitLab issue metadata

Behavior notes:

• the runtime resolves assignees by GitLab username
• the app searches for an existing open issue by rendered title and appends a hash of the source path to keep one issue per source object
• if an issue already exists, the app adds a note instead of opening a duplicate
• current validation requires at least one assignee

Duplicate Issue Handling#

The app does not use the rendered issue title by itself as the unique key.

For each triggering alarm or query event, the app:

• renders spec.issue.title
• computes a hash from the triggering object path in EDA state
• builds the final GitLab issue title as <rendered title> -- <hash>

This means duplicate-looking issue titles are handled as follows:

• if the same source object triggers again, the hash is the same, so the app finds the existing open issue and adds a note instead of creating another issue
• if two different source objects render the same title text, their source paths are different, so the hashes differ and the app creates separate issues
• if closeOnResolve is enabled, the app looks up the same hashed title and closes that matching issue when the source alarm clears or the query object disappears

In practice, the visible title in GitLab is intentionally suffixed with a hash so the app can safely distinguish repeated events from different objects even when the human-readable part of the title is identical.

apiVersion: gitlab.eda.nokia.com/v1alpha1
kind: GitlabIssue
metadata:
  name: influxdb-connection-issue
  namespace: eda
spec:
  trigger:
    alarm:
      include:
        - InfluxDBServerConnectionFailed
  repo: network-operations/eda-automation
  instance: gitlab-server
  closeOnResolve: true
  issue:
    title: "[ALERT] InfluxDB server connection failed"
    body: |
      Probable cause: {{ index . "probableCause" }}
      Last changed: {{ index . "lastChanged" }}
      Details: {{ index . "description" }}
    assignees:
      - network-ops
    milestone: Rel-25.10
    labels:
      - eda
      - alarm

cat << 'EOF' | kubectl apply -f -
apiVersion: gitlab.eda.nokia.com/v1alpha1
kind: GitlabIssue
metadata:
  name: influxdb-connection-issue
  namespace: eda
spec:
  trigger:
    alarm:
      include:
        - InfluxDBServerConnectionFailed
  repo: network-operations/eda-automation
  instance: gitlab-server
  closeOnResolve: true
  issue:
    title: "[ALERT] InfluxDB server connection failed"
    body: |
      Probable cause: {{ index . "probableCause" }}
      Last changed: {{ index . "lastChanged" }}
      Details: {{ index . "description" }}
    assignees:
      - network-ops
    milestone: Rel-25.10
    labels:
      - eda
      - alarm

EOF

GitLab Pipelines#

Use GitlabPipeline or ClusterGitlabPipeline to trigger a GitLab pipeline when an alarm or query event occurs.

Notable specification fields:

• trigger.alarm or trigger.query: trigger a GitLab pipeline when the matching alarm types or query updates occur
• repo: GitLab project path, typically in group/project form
• ref: branch, tag, or commit reference
• instance: referenced instance resource
• parameters[]: pipeline variables

Parameters can be:

• static with value.staticValue
• dynamic with value.dynamicValue, which fetches a field from EDA using the path, field, and optional where conditions

apiVersion: gitlab.eda.nokia.com/v1alpha1
kind: GitlabPipeline
metadata:
  name: interface-admin-down
  namespace: eda
spec:
  trigger:
    query:
      path: .namespace.node.srl.interface
      fields: []
      where: .namespace.node.name = "leaf-1" and name = "ethernet-1/9" and admin-state = "disable"
  repo: network-operations/eda-automation
  pipeline: ci.yml
  ref: main
  instance: gitlab-server
  parameters:
    - name: trigger_source
      value:
        staticValue: EDA
    - name: interface_name
      value:
        dynamicValue:
          path: .namespace.node{.name=="leaf-1"}.srl.interface
          field: name
          where: name = "ethernet-1/9" and admin-state = "disable"
    - name: interface_index
      value:
        dynamicValue:
          path: .namespace.node{.name=="leaf-1"}.srl.interface
          field: ifindex
          where: name = "ethernet-1/9" and admin-state = "disable"

cat << 'EOF' | kubectl apply -f -
apiVersion: gitlab.eda.nokia.com/v1alpha1
kind: GitlabPipeline
metadata:
  name: interface-admin-down
  namespace: eda
spec:
  trigger:
    query:
      path: .namespace.node.srl.interface
      fields: []
      where: .namespace.node.name = "leaf-1" and name = "ethernet-1/9" and admin-state = "disable"
  repo: network-operations/eda-automation
  pipeline: ci.yml
  ref: main
  instance: gitlab-server
  parameters:
    - name: trigger_source
      value:
        staticValue: EDA
    - name: interface_name
      value:
        dynamicValue:
          path: .namespace.node{.name=="leaf-1"}.srl.interface
          field: name
          where: name = "ethernet-1/9" and admin-state = "disable"
    - name: interface_index
      value:
        dynamicValue:
          path: .namespace.node{.name=="leaf-1"}.srl.interface
          field: ifindex
          where: name = "ethernet-1/9" and admin-state = "disable"

EOF

Cluster-Scoped Resources#

Use the cluster variants from the EDA base namespace when you want centralized automation across namespaces.

Cluster-specific behavior:

• ClusterGitlabIssue and ClusterGitlabPipeline can watch alarms across namespaces through trigger.alarm.namespaces
• query triggers can use fully qualified .namespace paths
• cluster resources must reference ClusterGitlabInstance

Workflow Resources#

The app also installs two workflow definition resources:

• CreateGitlabIssue
• RunGitlabPipeline

These workflows are run-to-completion programs that do not watch alarms or queries continuously; instead, they submit a single GitLab operation (issue or pipeline run) when the workflow is run.

apiVersion: gitlab.eda.nokia.com/v1alpha1
kind: CreateGitlabIssue
metadata:
  name: create-gitlab-issue-now
  namespace: eda
spec:
  instance: gitlab-server
  repo: network-operations/eda-automation
  issue:
    title: "Manual issue from EDA workflow"
    body: |
      This issue was created by the GitLab app workflow resource.
    assignees:
      - network-ops
    labels:
      - eda
      - workflow

cat << 'EOF' | kubectl apply -f -
apiVersion: gitlab.eda.nokia.com/v1alpha1
kind: CreateGitlabIssue
metadata:
  name: create-gitlab-issue-now
  namespace: eda
spec:
  instance: gitlab-server
  repo: network-operations/eda-automation
  issue:
    title: "Manual issue from EDA workflow"
    body: |
      This issue was created by the GitLab app workflow resource.
    assignees:
      - network-ops
    labels:
      - eda
      - workflow

EOF

apiVersion: gitlab.eda.nokia.com/v1alpha1
kind: RunGitlabPipeline
metadata:
  name: run-gitlab-pipeline-now
  namespace: eda
spec:
  instance: gitlab-server
  repo: network-operations/eda-automation
  pipeline: ci.yml
  ref: main
  parameters:
    - name: trigger_source
      value:
        staticValue: EDA
    - name: requested_by
      value:
        staticValue: workflow-cr

cat << 'EOF' | kubectl apply -f -
apiVersion: gitlab.eda.nokia.com/v1alpha1
kind: RunGitlabPipeline
metadata:
  name: run-gitlab-pipeline-now
  namespace: eda
spec:
  instance: gitlab-server
  repo: network-operations/eda-automation
  pipeline: ci.yml
  ref: main
  parameters:
    - name: trigger_source
      value:
        staticValue: EDA
    - name: requested_by
      value:
        staticValue: workflow-cr

EOF

Validation Notes#

When creating resources, follow these rules:

• instances require both authSecretRef.name and authSecretRef.key
• issues require repo, instance, issue.title, issue.body, at least one assignee, and either an alarm or query trigger
• issue title and body templates must be valid Go templates
• pipelines require repo, pipeline, ref, instance, and either an alarm or query trigger
• dynamic pipeline parameters must set at least one of field or path