The testing cycle for Release Notes Templates can be slow, requiring a build and release cycle. To try to speed this process for users I have created a local test harness that allows the same calls to be made from a development machine as would be made within a build or release.
However, running this is not as simple was you might expect so please read the instruction before proceeding.
Setup and Build
-
Clone the repo contain the Azure DevOps Extension.
-
Change to the folder
_
ExtensionsXplatGenerateReleaseNotesV2testconsole _
-
Build the tool using NPM (this does assume Node is already installed)
_npm install
npm run build_
Running the Tool
The task the testconsole runs takes many parameters, and reads runtime Azure DevOps environment variable. These have to be passing into the local tester. Given the number, and the fact that most probably won’t need to be altered, they are provided in settings JSON file. Samples are provided for a build and a release. For details on these parameters see the task documentation
The only values not stored in the JSON files are the PATs required to access the REST API. This reduces the chance of them being copied onto source control by mistake.
Two PATs are potentially used.
- Azure DevOps PAT (Required) - within a build or release this is automatically picked up. For this tool it must be provided
- GitHub PAT - this is an optional parameter for the task, you only need to provide it if working with private GitHub repos as your code store. So usually this can be ignored.
Test Template Generation for a Build
To run the tool against a build
-
In the settings file make sure the TeamFoundationCollectionUri, TeamProject and BuildID are set to the build you wish to run against, and that the ReleaseID is empty.
-
Run the command
_node .GenerateReleaseNotesConsoleTester.js build-settings.json
<Optional: your GitHub PAT> _
-
Assuming you are using the sample settings you should get an output.md file with your release notes.
Test Template Generation for a Release
To run the tool against a release is but more complex. This is because the logic looks back to see the most recent successful run. So if your release ran to completion you will get no notes as there has been no changes it it is the last successful release.
You have two options
- Allow a release to trigger, but cancel it. You can then use its ReleaseID to compare with the last release
- Add a stage to your release this is skipped, only run on a manual request and use this as the comparison stage to look for difference
To run the tool
-
In the settings file make sure the TeamFoundationCollectionUri, TeamProject, BuildID, EnvironmentName (as stage in your process), ReleaseID and releaseDefinitionId are set for the release you wish to run against.
-
Run the command
_node .GenerateReleaseNotesConsoleTester.js release-settings.json
<Optional: yourGitHub PAT> _
-
Assuming you are using the sample settings you should get an output.md file with your release notes.
Hope you find it useful