feat(detectors): add resource-detector-gitlab

[seiyar81]

Which problem is this PR solving?

• When running in a GitLab CI, OpenTelemetry should be able to automatically detect related attributes

Short description of the changes

• Added a new detector @opentelemetry/resource-detector-gitlab that detects and adds attributes based on environment variables as defined in the official GitLab documentation here
• Added tests for this new component
• New attributes are (but suggestions are welcome to enhance this list):

| Resource Attribute     | Description                                                                 |
|------------------------|-----------------------------------------------------------------------------|
| gitlab.user_email      | Value of Process Environment Variable `GITLAB_USER_EMAIL`                   |
| gitlab.user_id         | Value of Process Environment Variable `GITLAB_USER_ID`                      |
| gitlab.project_path    | Value of Process Environment Variable `CI_PROJECT_PATH`                     |
| gitlab.ref             | Value of Process Environment Variable `CI_COMMIT_REF_NAME`                  |
| gitlab.source          | Value of Process Environment Variable `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME` |
| gitlab.target          | Value of Process Environment Variable `CI_MERGE_REQUEST_TARGET_BRANCH_NAME` |
| gitlab.mr_iid          | Value of Process Environment Variable `CI_MERGE_REQUEST_IID`                |
| gitlab.pipeline_id     | Value of Process Environment Variable `CI_PIPELINE_ID`                      |
| gitlab.pipeline_source | Value of Process Environment Variable `CI_PIPELINE_SOURCE`                  |
| gitlab.commit_sha      | Value of Process Environment Variable `CI_COMMIT_SHA`                       |

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: seiyar81 (b30fadf)

[pichlermarc]

Hi @seiyar81 - it looks like this is a new component, so we require a few things before we can think about adding this:

• at least two owners that both are part of the OTel organization
  • see the requirements and responsibilities of a member
• any attributes MUST follow semantic conventions
  • see the CI/CD semantic conventions

Adding any component is a long-term commitment, therefore we need to ensure that we have the proper staffing for adding the component and that we follow best-practices laid out in the semantic conventions. In our experience, not doing so leads to a lot of churn for everyone involved and really slows down the development velocity of the project as a whole, as removing unmaintained components can take many months of on and off work.

We're happy to re-think this decision if these requirements are met.

[seiyar81]

Hi @seiyar81 - it looks like this is a new component, so we require a few things before we can think about adding this:

• at least two owners that both are part of the OTel organization

  • see the requirements and responsibilities of a member

• any attributes MUST follow semantic conventions

  • see the CI/CD semantic conventions

Adding any component is a long-term commitment, therefore we need to ensure that we have the proper staffing for adding the component and that we follow best-practices laid out in the semantic conventions. In our experience, not doing so leads to a lot of churn for everyone involved and really slows down the development velocity of the project as a whole, as removing unmaintained components can take many months of on and off work.

We're happy to re-think this decision if these requirements are met.

Ok ok I understand.
I simply copied and updated what was done for GitHub Actions as it follows the same spirit, and I'd really like to get involved.

So instead I could open a request for this feature to be added/studied ?

[pichlermarc]

I simply copied and updated what was done for GitHub Actions as it follows the same spirit, and I'd really like to get involved.

Mhm, unfortunately that one pre-dates the semantic conventions for CI/CD which is why it looks like this. 😅 I'm currently drafting a proposal to remove it from the repo.

So instead I could open a request for this feature to be added/studied ?

I think a feature request is the way to go, yes 🙂 It also helps us to determine how much interest there is in a component before adding it.

The current way to get components in is quite restrictive, but I am considering relaxing some of the constraints to align more with what collector-contrib is doing, which seems to be going well. In general, getting an approver or maintainer on board that will co-maintain the component will drastically increase the chances of this being added.

There are also other things that you could do in the meantime. 🙂 The rationale behind the detector interface being user-implementable is that everyone can start their own packages separate from the contrib repo. This helps in determining interest for such a component and gives more flexibility with regards to tooling and release cycles.