Add best-effort strategy to find the valid Git commit in Jenkins Pipelines traces.#214
Conversation
| return false; | ||
| } | ||
|
|
||
| return SHA1_PATTERN.matcher(gitCommit).matches(); |
There was a problem hiding this comment.
nit but maybe this could be faster if the regex is any non-alphanumeric because you're already checking length before and it could stop at the first non allowed character
| // If we could not detect a valid commit, that means that the GIT_COMMIT environment variable | ||
| // was overridden by the user at top level, so we set the content what we have (despite it's not valid). | ||
| // We will show a logger.warning at the end of the pipeline. | ||
| final String gitCommit = (isValidCommit(envVars.get("GIT_COMMIT"))) ? envVars.get("GIT_COMMIT") : buildData.getGitCommit(""); |
There was a problem hiding this comment.
nit I would copy envVars.get("GIT_COMMIT") to a temporary var to make this simpler
| buildSpan.setTag(CITags.GIT_COMMIT__SHA, gitCommit); //Maintain retrocompatibility | ||
| buildSpan.setTag(CITags.GIT_COMMIT_SHA, gitCommit); |
There was a problem hiding this comment.
Should this still happen if gitCommit is not valid?
There was a problem hiding this comment.
I'd say yes because we need git information to correlate traces for pipeline/stages/jobs spans (atm). We're showing a warning in the logs, though.
If the commit is not "valid", that means the user modified it explicitly... so, we may want to show what the user set (most probably a short version of the commit).
Requirements for Contributing to this repository
What does this PR do?
This PR adds some mechanisms to find the valid Git commit to use in Jenkins Pipelines traces.
During the process of building the pipeline traces, the Git information is only available when an actual step is executed (via environment variables), so we're updating the global information for Git during this process.
There could be scenarios where the step modifies the
GIT_COMMITenvironment variable, (e.g. to set a short version of it). In this case, if during other steps we found a valid SHA1 commit (40 char length), we want to use that commit in all spans of the traces.This approach is "best effort" because if the user overrides the
GIT_COMMITenvironment variable at top level of the pipeline, we cannot find a valid commit. In this case, we set the value that we obtained, showing a warning in the Jenkins log file.Description of the Change
Alternate Designs
Possible Drawbacks
Verification Process
Additional Notes
Release Notes
Review checklist (to be filled by reviewers)
changelog/label attached. If applicable it should have thebackward-incompatiblelabel attached.do-not-merge/label attached.kind/andseverity/labels attached at least.