Label Schema

The integrations repository uses several types of labels to manage issues and pull requests effectively. Below is a summary of the label schema:

Integration Labels

• Format: Integration:{package_name} (where package_name is the value of the name field in the package's manifest.yml) (labels longer than 50 characters are truncated to meet GitHub requirements)
• Uniqueness: Package names are guaranteed to be unique by CI in the elastic/integrations repository. This guarantee exists because packages are no longer required to live under the top-level packages/ directory, so directory names are no longer unique across the repo.
• Color:
  • Active integrations (exists in main): FFFFFF (white)
  • Deprecated integrations: F9D0C4 (pale pink)
  • Inactive integrations (does not exist in main): D3D3D3 (light to medium gray)
• Description: Contains the integration title (taken from the manifest), optionally followed by support information:
  • Partner supported: "(Partner supported)"
  • Community supported: "(Community supported)"
  • Integration does not exist in main branch of the repository: "[Integration not found in source]"
• Purpose: Identifies which integration package an issue or PR is associated with. Because GitHub has a limit of 100 labels per issue or pull request, there is a special Integration:All label that should be used for bulk changes. For pull requests, the integration labels should correlate directly to the modified packages.
• Label Creation: Integration:* labels are created automatically after a new integration merges to the main branch. This ensures the label reflects the final package name from manifest.yml, which can still change during review. Do not create the label manually beforehand — use the general New Integration label on the PR instead.

Team Labels

• Format: Team:{team_name}
• Color: 1D76DB (slightly teal-leaning blue)
• Description: Optional team description followed by GitHub team name in brackets [{github_team}]
• Purpose: Identifies which team is responsible for review/maintenance. For packages that have shared ownership defined in CODEOWNERS, only the team labels specific to the associated changes should be applied (as opposed to the label of the overall package owner defined in the package's manifest). These are the mappings between GitHub teams and labels.

github_team	label_name	label_description
@elastic/cloud-services	Team:Security-Cloud Services	Security Data Experience - Cloud Services team
@elastic/ecosystem	Team:Ecosystem	Packages Ecosystem team
@elastic/elastic-agent-data-plane	Team:Elastic-Agent-Data-Plane	Agent Data Plane team
@elastic/elastic-agent	Team:Elastic-Agent	Platform - Ingest - Agent
@elastic/fleet	Team:Fleet	Fleet team
@elastic/integration-experience	Team:Integration-Experience	Security Integrations Integration Experience
@elastic/obs-cloudnative-monitoring	Team:Cloudnative-Monitoring	Cloud Native Monitoring team
@elastic/obs-ds-hosted-services	Team:obs-ds-hosted-services	Observability Hosted Services team
@elastic/obs-infraobs-integrations	Team:Obs-InfraObs	Observability Infrastructure Monitoring team
@elastic/obs-ux-infra_services-team	Team:obs-ux-infra_services	Obs UX: Infra & Services team
@elastic/search-extract-and-transform	Team:Search-Extract and Transform	Search - Extract and Transform team
@elastic/sec-applied-ml	Team:Security-Applied ML	Elastic Security Protections Machine Learning (ML) team
@elastic/sec-deployment-and-devices	Team:Security-Deployment and Devices	DEPRECATED Deployment and Devices Security team
@elastic/sec-linux-platform	Team:Security-Linux Platform	Linux Platform Security team
@elastic/sec-windows-platform	Team:Security-Windows Platform	Security Windows Platform team
@elastic/security-asset-management	Team:Asset Mgt	Security Assets Management team
@elastic/security-defend-workflows	Team:Defend Workflows	Security team for Endpoint and OSQuery workflows
@elastic/security-service-integrations	Team:Security-Service Integrations	Security Service Integrations team
@elastic/sit-crest-contractors	Team:SDE-Crest	Crest developers on the Security Integrations team
@elastic/stack-monitoring	Team:Stack Monitoring	Stack Monitoring team
@elastic/workflows-eng	Team:One Workflow	Workflow Automation team

Maintainer Labels

• Format: maintainer:{type}
• Examples: maintainer:Partner, maintainer:Community
• Color: 40E8AD (teal-green)
• Purpose: Sets expectations with issue reporters about support level. To avoid label noise, there is no maintainer:Elastic label. This corresponds to the owner.type defined in the package's manifest.

CLA Label

• Examples: needs CLA
• Purpose: Indicates that the pull request author has not signed the Elastic contributor license agreement (CLA). Label status should be determined based on the result of the latest commit status posted by the CLA Checker bot.

Change Summary Labels

• Examples: New Integration, dashboard, bugfix, enhancement, breaking-change
• Purpose: Indicates the type of changes in a pull request.
• Management: Applied based on:
  • bugfix, enhancement, and breaking-change should be applied based on the change types added to the changelog.yml files in the pull request
  • dashboard should be applied when a file matching <package_path>/kibana/dashboard/*.json is added or modified (where <package_path> is the repo-relative path to a package directory, typically under packages/)
  • documentation should be applied when any file with a .md extension is added or modified
  • New Integration is applied when a new package is added. It serves as a stand-in for the eventual Integration:{package_name} label, which is only created once the package merges to main (see Integration Labels)