Expose scm material url and branch as environment variables to tasks

[granddesigntech]

Issue Type

• Feature enhancement

Summary

I need to be able to pass the following values to the build process I am executing (creating a pipeline to orchestrate the build, test & release automations of another team):

• commit id
• scm url
• branch name
• version

currently only the commit id and version are exposed as environment variables to the task.

Request is to add the scm url and branch name to the set of material metadata being exposed as env vars to tasks.

[arvindsv]

I'm usually up for providing more information. In these cases though, assuming git for now, these are available using command such as:

git config --get remote.origin.url
git branch --points-at HEAD --format "%(refname:short)"

Right? Isn't that enough? Trying to understand whether it's about convenience or something more than that.

Of course, one of the issues we'd need to look at if URL is provided is that the URL might have credentials in some cases.

[granddesigntech]

More detail: I specifically didn't include more detail because I wanted the request to reflect the level of knowledge the pipeline task has when it has to perform what it has to perform. It should not have to know whether it is a git repo or an svn repo or any other. That knowledge is nicely compartmentalised into the material handling and should stay there.

Usecase: The above not withstanding there are some times when the user or beneficiary of the automation might benefit from some (fairly generic across scm tools) information configured, generated or otherwise identified during material handling that the task itself should not need to know the toolset involved to retrieve (eg branch, remote repo url, change id, etc) as once you are manipulating tools specific to the material in subsequent tasks that pipeline stage is now broken if the material source/toolset changes and reusability across SCM repos is impossible without unwieldy cludges.
Particularly since the product IS exposing values the SCM plugin has to use the toolset or API specific to the SCM in play to determine it seems somewhat churlish not to expose values that have already been entered explicitly by the user. Why make them then pollute their task with out of place knowledge (ie of what SCM toolset to use) and code to find out what they have already entered?

Credentials: It would seem prudent to elide passwords found in the url format password location or values of query section fields like "password", "passwd", "pass", etc.

[rajiesh]

Verified on 19.10.0 (10328-5cb62ca14461d56576551e0bbec2978c909ea9b2)