Adding Azure DevOps to known BRANCH_ENV_VAR_NAMES

[mcmurd]

Appreciate that the universe of build tools is exhaustive, however, the rationale for requesting Azure Devops be added is that repo checkouts through Azure Pipelines results in a DETACHED HEAD.

When the branch is being validated as part of execution of this library (git rev-parse --abbrev-ref HEAD), it evaluates to "HEAD" which in turn is stripped through the reject method on execute_and_parse_command which then results in a failed validation.

We have the Azure DevOps pipeline variable $(Build.SourceBranch).

There are perhaps many more ways to address this scenario, but it looks as though this suggestion may be consistent with some of the other tools that have been considered within BRANCH_ENV_VAR_NAMES

[bethesque]

Happy to add support for Azure DevOps. We need to identify the relevant environment variable. It looks like this describes the name mapping https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#environment-variables

From that, I would expect it to be $BUILD_SOURCE_BRANCH. Could you verify this for me? And can you find the equivalent for the git sha? Thanks.

[bethesque]

I'm actually surprised that it's not already being picked up. As you can see in this method, if it can't find a known env var, it tries to find the shortest environment variable name ending with _BRANCH, so BUILD_SOURCE_BRANCH should already be picked up.

[bethesque]

Sorry, I remembered that incorrectly - it only returns the value if there was only ONE environment variable ending in _BRANCH, and there are probably multiple env vars ending in _BRANCH found for the build.

[mcmurd]

Traced out env vars on an Azure linux build agent. For git SHA and the branch name, the env variables are:

$BUILD_SOURCEVERSION
$BUILD_SOURCEBRANCHNAME

Whilst there is more than 1 env variable with BRANCH available on the build agent, they are not preceded by an underscore. So I suspect that's why it doesn't catch as default.

[mcmurd]

Traced out env vars on an Azure windows build agent and they are the same as on the linux distro (just checking !).

[bethesque]

I've added those to env vars to the list and I've just triggered the release of the pact broker client gem. It should update all the libraries that contain it over the next few minutes. Try updating your package and see if it works for you.

[mcmurd]

Updating Pact to latest version:

"@pact-foundation/pact": "^9.18.0"

Pact has a dependency upon pact-node, the latest being 10.17.4.

Not sure on the correlation between the npm package version and the tags on pact-js-core (currently v13.6.0).

However, if I look at the latest source on pact-js-core, I can see that pact-js-core/standalone/install.ts pulls in https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.89.02-rc1

Checking the release notes for this RC, I can see that it references pact_broker-client gem 1.65.0 (as expected).

Therefore, I would expect that I am running the updated pact_broker-client.

Error is still:

PactBroker::Client::Error - Command git rev-parse --abbrev-ref HEAD didn't return anything that could be identified as the current branch.

To try to remove any ambiguity between package dependencies, I've included an explicit gem install and checked the package version to be 1.65.0.

Still results in the same error as above.

Tracing out env vars to confirm that they are definitely being set:

BUILD_SOURCEVERSION 8a61d5057550f02309061cd6542cb4937d45a295
BUILD_SOURCEBRANCHNAME 801-update-build-pipeline-with-dot-env

[bethesque]

@mefellows can you verify the dependency versions?

Pact has a dependency upon pact-node, the latest being 10.17.4.

I thought pact-node didn't exist any more.

[mefellows]

The repo is called pact-js-core, but it produces two packages: pact-node (currently in use by stable pact js) and pact-core (currently in use by beta Pact JS). Both have the same version of the ruby core (1.89.01-rc1) bundled in at the time of posting.

Yes, it's confusing, and yes, this is why we need to get the beta to stable ASAP so we can get back to a single deployable unit from both repos.

[mefellows]

@mefellows can you verify the dependency versions?

Pact has a dependency upon pact-node, the latest being 10.17.4.

I thought pact-node didn't exist any more.

And yes, this is the latest version of that package as at today with the bundled ruby core version 1.89.01-rc1

[mefellows]

OK I see there is a PR - merging and releasing a new one now (both pact-core and pact-node ;) ).

[mefellows]

pact-node 10.17.5 has been published, you should be able to npm update for any Pact JS projects and this should update automatically.

[bethesque]

I'm assuming this is working now. Please re-open if not.