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 directory name containing the package)
• 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)"
• 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: New labels will be added after a new integration merges to the main branch. Before that time, use the general New Integration label.

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-security-posture	Team:Cloud Security	Cloud Security team
@elastic/ecosystem	Team:Ecosystem	Packages Ecosystem team
@elastic/elastic-agent	Team:Elastic-Agent	Platform - Ingest - Agent
@elastic/elastic-agent-data-plane	Team:Elastic-Agent-Data-Plane	Agent Data Plane team
@elastic/fleet	Team:Fleet	Fleet team
@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	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-service-integrations	Team:Security-Service Integrations	Security Service Integrations team
@elastic/stack-monitoring	Team:Stack Monitoring	Stack Monitoring team
@elastic/sit-crest-contractors	Team:Sit-Crest	Crest developers on the Security Integrations 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 packages/*/kibana/dashboard/*.json is added or modified
  • New Integration is applied when a new package is added