Integrations

Govlin links each change to its ticket, pipeline, quality result and approvals. The Desktop sees the Git operations made from the app; the rest arrives from your integrations. The Action Center shows What Govlin receives today, one line per integration, and names each state: Connected, No data or Not set up.

Administrators choose the integrations in Settings → Setup → Integrations.

---

GitHub

A repository webhook with a shared secret. Govlin receives pushes, branch creation, pull requests, reviews, review comments, pull request comments, check runs, check suites and statuses.

• Every delivery is verified with its HMAC signature before it is accepted.
• Every accepted delivery leaves a receipt, and a reconciler asks GitHub to redeliver any delivery without one, so none disappears silently.
• Pull request titles and comments count for traceability only when they contain a ticket ID.

Jira

A native Jira webhook signed with a shared secret (X-Hub-Signature), for issues created, updated and deleted in your project. Govlin links a change to the tickets its commit message or branch cite in the same moment it stores the change, and a merged pull request to the tickets its title or comments cite when its webhook arrives.

Evidence → Tickets without code lists the tickets no change cites.

Jenkins

Add a step to your Jenkinsfile that sends each run to Govlin:

pipeline {
    agent any
    environment {
        GITGOV_URL = 'https://your-govlin-server'
        GITGOV_KEY = credentials('gitgov-admin-api-key')
    }
    stages {
        stage('Build') {
            steps {
                // ... your existing build steps ...
            }
        }
        stage('Test') {
            steps {
                // ... your existing test steps ...
            }
        }
        stage('Deploy') {
            steps {
                // ... your existing deploy steps ...
            }
        }
    }
    post {
        always {
            script {
                def result = currentBuild.result ?: 'SUCCESS'
                def ts     = System.currentTimeMillis()
                sh """
                    curl -s -X POST \${GITGOV_URL}/integrations/jenkins \\
                      -H "Authorization: Bearer \${GITGOV_KEY}" \\
                      -H "Content-Type: application/json" \\
                      -d '{
                        "pipeline_id": "\${env.BUILD_TAG}",
                        "job_name":    "\${env.JOB_NAME}",
                        "status":      "\${result.toLowerCase()}",
                        "commit_sha":  "\${env.GIT_COMMIT}",
                        "branch":      "\${env.GIT_BRANCH}",
                        "repo_full_name": "YourOrg/YourRepo",
                        "duration_ms": \${currentBuild.duration},
                        "triggered_by": "\${env.BUILD_USER_ID ?: 'ci'}",
                        "timestamp":   \${ts},
                        "stages": [
                          {"name": "Build",  "status": "success", "duration_ms": 134000},
                          {"name": "Test",   "status": "success", "duration_ms": 272000},
                          {"name": "Deploy", "status": "success", "duration_ms": 63000}
                        ]
                      }'
                """
            }
        }
    }
}

Store the key as a Jenkins credential of type Secret text. The endpoint requires an administrator key; Govlin never shows a key twice.

SonarQube

Quality gate results are linked to the pipeline run and the commit they belong to. They appear as Quality in the details of a change and in the Quality group of Rules.

GitHub Actions

Settings → Setup generates a workflow pack from your organization profile. You install it through a reviewed pull request and then run the read-only installation check. Govlin checks the names of the variables and secrets the pack needs, never their values.

---

Asking Govlin from the CI

Rule check

Your pipeline can ask Govlin whether a commit meets the repository rules:

stage('Policy Check') {
    steps {
        script {
            def response = sh(
                script: """curl -s -X POST \${GITGOV_URL}/policy/check \\
                  -H "Authorization: Bearer \${GITGOV_KEY}" \\
                  -H "Content-Type: application/json" \\
                  -d '{"repo": "YourOrg/YourRepo", "commit": "\${env.GIT_COMMIT}", "branch": "\${env.GIT_BRANCH}"}'""",
                returnStdout: true
            ).trim()
            echo "Govlin policy check: ${response}"
            // Parse response and optionally fail the build on violations
        }
    }
}

The response includes allowed, reasons and warnings. It is advisory unless you add failure logic, or the rules of that scope are set to block.

Deployment authorization

Before deploying, the CI can request a deployment authorization for a commit and an environment. Govlin evaluates the release and records the authorization. That is how a release appears in Releases with its state per environment. With the default Record only policy the authorization never blocks.