Feature Request: Capture the "agent" that triggers the build as the user

[yogurtearl]

Would be nice if they user name in gradle enterprise was the person that triggered the build.

Looks like gradle enterprise reads it from "user.name", so you could set that property. Else would be nice if gradle enterprise provided a dsl to set it.

Either way, this plugin could set the user name on various CI systems:

for GH actions:

providers.environmentVariable("GITHUB_ACTOR").orNull?.let { System.setProperty("user.name", it) }

for Jenkins: (with https://plugins.jenkins.io/build-user-vars-plugin/)

providers.environmentVariable("BUILD_USER_ID").orNull?.let { System.setProperty("user.name", it) }

[runningcode]

You can change the user ID using the obfuscation api on the username field. https://docs.gradle.com/enterprise/gradle-plugin/#obfuscating_identifying_data

I'm not sure if changing the agent is the behavior we want for all builds but we appreciate the suggestion and are considering it.

We encourage you to fork the common custom user data plugin and customize it for your needs.

Here is an example of setting the username based on the GITHUB_ACTOR environment variable:

gradleEnterprise {
    buildScan {
        obfuscation {
            username { name -> System.getenv("GITHUB_ACTOR")?:name }
        }
    }
}

[etiennestuder]

@yogurtearl I suggest to proceed as following:

• if you have a single repo where you apply the CCUD plugin, use the snippet above to override the username to your specific needs and environments
• if you have multiple repos where you apply the CCUD plugin, derive your own company-internal plugin from the CCUD plugin and adjust it to your needs, possibly also configuring the GE URL, the build cache settings, etc. in that plugin (see also here for a template), we see this working successfully in many companies

[yogurtearl]

derive your own company-internal plugin from the CCUD plugin and adjust it to your needs

If I need this for an OSS project, and want to use it across a few different projects, would you suggest just make an OSS fork, and publish it under something like com.yogurtearl.gradle:common-custom-user-data-gradle-plugin ?

[etiennestuder]

• For company-internal usage, I would clone the CCUD plugin, adjust its configuration of GE, and publish the cloned plugin to an internal repository like Nexus or Artifactory.
• For OSS usage, I would not clone the CCUD plugin but make the changes right in the OSS projects, even if it means duplicating the few lines of code listed above. In case that minor duplication is unacceptable, I would create a new plugin that is applied post CCUD plugin and just adds the few bits of different configuration (instead of duplicating the entire CCUD plugin).