GitLab and Jira integration
Linking self-managed GitLab with Jira Cloud or Data Center: the Jira issues integration versus the development panel, which features each gives, and what project data becomes visible in Jira.

Connecting self-managed GitLab to issue trackers, secrets managers, Kubernetes clusters, chat and other CI systems through its documented integrations.
Linking self-managed GitLab with Jira Cloud or Data Center: the Jira issues integration versus the development panel, which features each gives, and what project data becomes visible in Jira.
Pulling CI/CD secrets from HashiCorp Vault or other external secrets managers with ID tokens, the Premium tier requirement, and Vault roles that limit secrets by project and branch.
Connecting GitLab to Kubernetes clusters with the agent: GitOps with Flux versus CI/CD access, agentk and KAS on self-managed GitLab, supported Kubernetes versions and moving off certificate-based clusters.
Running Mattermost next to GitLab after the bundled component was removed in GitLab 19: notifications, slash commands and single sign-on between the two.
Triggering Jenkins pipelines from GitLab and reporting status back to merge requests, used while CI/CD moves to GitLab gradually or where Jenkins jobs must stay.
Using Redmine as the external issue tracker for GitLab projects: linking issue references in commits and merge requests, and when to move issues into GitLab instead.
Using Harbor as the container registry for GitLab projects: the group or project-level settings, the six HARBOR_* CI/CD variables pipelines use to push and pull, and how project settings override group defaults.
Replacing long-lived cloud keys in CI/CD variables with ID tokens: how jobs exchange a JWT for temporary AWS, Azure or Google Cloud credentials, the aud and sub claims to condition roles on, and why stable project IDs matter after renames.
Choosing between project or group webhooks and instance-wide system hooks, signing payloads with HMAC-SHA256 instead of the plain secret token, and handling the automatic disabling of failing webhooks.
Sending GitLab pipeline and job data to Datadog: the instance, group or project settings, the optional CI Visibility and job log collection, and the per-committer billing to check with Datadog first.
Moving GitLab Teams notifications off retired Office 365 connectors to a Power Automate workflow: the template change GitLab documents, the events to enable and limiting pipeline alerts to broken pipelines.
Keeping issues in an external tracker while code lives in GitLab: which trackers GitLab integrates natively, the custom issue tracker option for others, and inheriting the setting from the instance or group.
Setting integration defaults once for a self-managed instance: instance and group settings, project inheritance and overrides, and the integration allowlist administrators use to limit which integrations can be enabled.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.