Add fallback logic for job name and build tag in build data

[nikita-tkachenko-datadog]

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?

Adds fallback behaviour to the logic that populates job name, job base name and build tag:

• If job name could not be populated, JOB_NAME is used to fill it
• If job base name could not be populated, JOB_BASE_NAME (or JOB_NAME if base name is not available) is used to fill it
• If build tag could not be populated, concatenation of jenkins-${JOB_NAME}-${BUILD_NUMBER} is used to fill it

CI Visibility backend requires these values to be non-empty. If any of them is not provided, corresponding events will be dropped.

Description of the Change

Alternate Designs

Possible Drawbacks

Verification Process

The new logic is covered with unit tests.

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]

For the JOB_BASE_NAME, wouldn't better to check if the env var is set, and if not, use the getJobName functions?

Suggested change

	String jobName = job.getName();
	if (StringUtils.isNotBlank(jobName)) {
	return jobName;
	}
	if (envVars != null) {
	String envJobBaseName = envVars.get("JOB_BASE_NAME");
	if (StringUtils.isNotBlank(envJobBaseName)) {
	return envJobBaseName;
	}
	String envJobName = envVars.get("JOB_NAME");
	if (StringUtils.isNotBlank(envJobName)) {
	return envJobName;
	}
	}
	return "unknown";
	if (envVars != null) {
	String envJobBaseName = envVars.get("JOB_BASE_NAME");
	if (StringUtils.isNotBlank(envJobBaseName)) {
	return envJobBaseName;
	}
	}
	return getJobName(run, envVars);

[nikita-tkachenko-datadog]

I was afraid to change the logic too much, since I didn't know what the difference was between the API and the environment variables. That is why I added using the latter only as a fallback - to minimise the changes in behaviour.

If we can be sure that the env var never contradicts whatever is reported by the API, then surely we can change it.
What do you think?

[drodriguezhdez]

I would say that the API and env var should be aligned, but I don't have enough context of the Jenkins core implementation to put my finger on it 😅.

[nikita-tkachenko-datadog]

Judging by the core code it does seem to be the case. Still I think we should err on the side of caution.

I have changed getBaseJobName to delegate to getJobName similarly to what you suggested, but still left the API as the higher priority option, so the behaviour is the following:

1. Try to get the base name from the API
2. Fall back to JOB_BASE_NAME
3. Fall back to getJobName