Add ability to customize build tags from groovy pipelines about datadog-plugin HOT 13 CLOSED

Hey there,
We've just released v2.0.0 of the Datadog plugin for Jenkins which provides better support for pipelines. It also adds a datadog step that can be used from within pipelines definition to set custom tags like so

• Declarative

def cause = 'something';
pipeline {
    agent any
    options {
        datadog(collectLogs: true, tags: ["cause:${cause}"])
    }
    stages {
        stage('Example') {
            steps {
                echo "Hello world."
                sh 'sleep 15'
            }
        }
    }
}

• Scripted

def cause = 'something'

datadog(collectLogs: true, tags: ["cause:${cause}"]){
  node {
    stage('Example') {
      echo "Hello world."
      sh 'sleep 15'
    }
  }
}

from datadog-plugin.

In order to fix this properly, i would love to better understand user scenario (note that i didn't created this issue, i just migrated it from our old repo to this new one).

Would anyone have a clear and simple scenario to share? Ideally something that we could use as a test scenario (groovy pipeline and/or jenkinsFile). The hack mentioned above wasn't very clean and ideally, i would like something more standard and generic.

@provCristianMaluenda that seems like a different feature request. Do you mind to open a distinct issue for it?

from datadog-plugin.

I created this feature request.

Thanks @gzussa

from datadog-plugin.

Hey all here, I spent some time playing around with some of the provided use cases and I was able to get a better understanding of the situation.

By setting tagProperties: "key=${VALUE}" (note the double quotes), Jenkins will resolve the environment variables on each build and will update DatadogJobProperty. This is not how DatadogJobProperty is supposed to work, its configuration is supposed to be static between builds.

For dynamic properties (like tagging), the plugin does support resolving environment variables. But to do so, you need to set tagProperties: 'tag_key=${VALUE}' (note the single quotes), so that the plugin can try to resolve environment variables on each build and have a dynamic value.

Yet, you've clearly noted that the plugin is not able to resolve variables (and replace ${XYZ} with _xyz) in case of pipeline builds, so what's going on?
It appears that the environment where jenkins agents run the pipeline scripts and the environment where the pipeline (and the datadog plugin) run are different. So from the standpoint of the datadog plugin, there is no access to those env vars.
Some links pointing to that:
https://stackoverflow.com/a/60781824
https://stackoverflow.com/q/52704473

As pointed out by @s2oBCN the PR DataDog/jenkins-datadog-plugin#164 seems to go in the right direction, but as far as I can tell it does't seem to solve the problem as env vars resolution still takes place in the wrong scope. I think the way forward here is to add a DatadogBuildStep that will take care of resolving the env vars during the run.

from datadog-plugin.

The most relevant PR to look at is DataDog/jenkins-datadog-plugin#164 (from the old repo).
The second related issue is DataDog/jenkins-datadog-plugin#152

from datadog-plugin.

I just was thinking of a similar requirement. It would be great if we can use env vars in the "Global job tags".
Something like (.*?)/(.*?)/(.*?),a:$,b:$2,c:$3,team:$TEAM_NAME 🤔

from datadog-plugin.

The hack @gzussa describes to set tags dynamically in the original post also no longer works in v1.0.x of the plugin, so even the little ability we had to do this is gone (unless we stick to 0.7.1).

from datadog-plugin.

For me (author of the original issue) the use case was and still is the following.

We have a shared library that allows executing specific types of builds based on GitHub comments. More specifically it supports deploying a service when a user writes !deploy in a PR comment. To gather metrics about deploys we differentiate between regular builds and deploys with a is_deploy tag in Datadog. The problem is that the tag can currently get an invalid value if deploys and regular PR builds run concurrently. To avoid that, we abort all other builds whenever a deploy starts. The actual code for this can be seen here.

For a simple scenario, however, something like this should do (haven't tested):

def isCommentTriggeredBuild = !!currentBuild.rawBuild.getCause(org.jenkinsci.plugins.pipeline.github.trigger.IssueCommentCause)
properties([
  pipelineTriggers([issueCommentTrigger('!trigger-build')]),
  [
    $class: 'DatadogJobProperty',
    enableProperty: true,
    tagProperties: "is_comment_triggered_build=${isCommentTriggeredBuild}"
  ]
])

from datadog-plugin.

Oh, and the triggering requires https://github.com/jenkinsci/pipeline-github-plugin

from datadog-plugin.

Ok, we will have to evaluate what the best approach is here.

from datadog-plugin.

Hi! How is this PR? We need this feature too :)

from datadog-plugin.

Well, in fact, we see that this PR DataDog/jenkins-datadog-plugin#164 seems to be fine for us.
Is this possible to merge?
Thank you!

from datadog-plugin.

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community.

If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of this project.

2. Comment that the issue is still reproducible and include updated details requested in the issue template.

from datadog-plugin.