Skip to content

Fixes for Jenkins pipelines traces tags#119

Merged
drodriguezhdez merged 4 commits into
masterfrom
drodriguezhdez/fix_metadata_traces
Sep 3, 2020
Merged

Fixes for Jenkins pipelines traces tags#119
drodriguezhdez merged 4 commits into
masterfrom
drodriguezhdez/fix_metadata_traces

Conversation

@drodriguezhdez

Copy link
Copy Markdown
Collaborator

DISCLAIMER

This PR adds an experimental feature in alpha state.
Internal use only.

Requirements for Contributing to this repository

  • Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
  • The pull request must only fix one issue at the time.
  • The pull request must update the test suite to demonstrate the changed functionality.
  • After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

This PR contains the following changes in the tags for Jenkins pipelines spans:

  • Changed tags of Start of pipeline span from ci.pipeline.* to ci.job.*
  • Removed IDs from pipeline spans.
  • The generated node id in the graph is now set into ci.job.number tag.
  • Removed branch name from ci.pipeline.name and resource.name
  • Changed ci.job.url to <pipeline_url>/execution/node/<job_id>/

Description of the Change

Alternate Designs

Possible Drawbacks

Verification Process

Additional Notes

Release Notes

Review checklist (to be filled by reviewers)

  • Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
  • PR title must be written as a CHANGELOG entry (see why)
  • Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
  • PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
  • PR should not have do-not-merge/ label attached.
  • If Applicable, issue must have kind/ and severity/ labels attached at least.

@drodriguezhdez drodriguezhdez added the changelog/Fixed Fixed features results into a bug fix version bump label Sep 2, 2020
@drodriguezhdez drodriguezhdez self-assigned this Sep 2, 2020
@drodriguezhdez
drodriguezhdez force-pushed the drodriguezhdez/fix_metadata_traces branch from 953114f to ec6f4f5 Compare September 2, 2020 15:19
@drodriguezhdez
drodriguezhdez marked this pull request as ready for review September 2, 2020 15:19
final long endTimeMicros = buildData.getEndTime(0L) * 1000;
buildSpan.setTag(DDTags.SERVICE_NAME, "jenkins");
buildSpan.setTag(DDTags.RESOURCE_NAME, buildData.getJobName(null));
buildSpan.setTag(DDTags.RESOURCE_NAME, removeBranchSuffix(buildData.getJobName(null)));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For context, what is this tag for, why does the job name contains the branch in it, and are we sure this method will not remove important information?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the user triggers a multibranch pipeline, the job name contains a suffix with the branch. This suffix needs to be removed to treat all pipeline executions related to the same pipeline item as the same resources in Datadog (and not per branch)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue with Jenkins though is that plugins have a lof of freedom. The multibranch plugin will create one "Project/Job" per branch in the repo and indeed will add the name of the branch to the Job name.
We're here tackling an specific behavior of one specific plugin. But other plugins can do similar things that won't be handled by this change.

I think a best bet would be limit this specific behavior to cases where we are sure that the Job comes from a multibranch pipeline. I'm sure there's a way to tell that without depending on the multibranch plugin either. Maybe check the list of action and check if one of the action's class name matches a multibranch action?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function will simply remove anything after the first /.
If a non multibranch project has a / in the name, the suffix will get removed unintentionally

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to remove this specific logic from this PR. As you mention, more things need to be considered and it will be adjusted in other specific PR.

@drodriguezhdez
drodriguezhdez force-pushed the drodriguezhdez/fix_metadata_traces branch from 11b3ca1 to 9e25ca1 Compare September 3, 2020 11:11
FlorianVeaux
FlorianVeaux previously approved these changes Sep 3, 2020
@drodriguezhdez
drodriguezhdez merged commit 6828408 into master Sep 3, 2020
@drodriguezhdez
drodriguezhdez deleted the drodriguezhdez/fix_metadata_traces branch September 3, 2020 12:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog/Fixed Fixed features results into a bug fix version bump

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants