Write unit tests for build and sign release

[james-garriss]

🗣 Description

Moved some of the build and sign release into a function. Reused existing unit tests and wrote a new one.

Note: Testing Azure Sign Tool itself should be a functional test that is added to nightly tests. A new issue was created for this (#1520).

💭 Motivation and context

Closes: #1453

🧪 Testing

Ran workflow pipeline, checked the results.

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• PR targets the correct parent branch (e.g., main or release-name) for merge.
• Changes are limited to a single goal - eschew scope creep!
• Changes are sized such that they do not touch excessive number of files.
• All future TODOs are captured in issues, which are referenced in code comments.
• These code changes follow the ScubaGear [content style guide]
• Related issues these changes resolve are linked preferably via [closing keywords]
• All relevant type-of-change labels added.
• All relevant project fields are set.
• All relevant repo and/or project documentation updated to reflect these changes.
• Unit tests added/updated to cover PowerShell and Rego changes.
• All automated checks (e.g., linting, static analysis, unit/smoke tests) passed.

✅ Pre-merge checklist

• PR passed smoke test check.

• Feature branch has been rebased against changes from parent branch, as needed

  Use Rebase branch button below or use this reference to rebase from the command line.

• Resolved all merge conflicts on branch

• Notified merge coordinator that PR is ready for merge via comment mention

• Demonstrate changes to the team for questions and comments.
  (Note: Only required for issues of size Medium or larger)

✅ Post-merge checklist

• Feature branch deleted after merge to clean up repository.
• Verified that all checks pass on parent branch (e.g., main or release-name) after merge.

[buidav]

I think the workflows are now in a position where we could refactor out having to using a slimmer version of this function to pull out the version number from the manifest. Future enhancement of course.

[james-garriss]

I like the concept, and I'm willing to use it, but I don't like the implementation. If pulling values from a "config file" requires a regex, we're doing it wrong. Surely there's a smarter way!? Or a different type of "config file" could be used for such values?

Well, whatever the implementation, I recommend creating an issue to do this work in the future.

[james-garriss]

I added a note to my code stating that this might be coming.

[buidav]

A question.
Is this unit test ever meant to be run locally?

If yes, then would it beneficial to check if the AzureSignInTool is already installed before attempting to do another installation?
If no, disregard question.

[james-garriss]

Functions that are in /utils are intended to be used and reused by any code. Functions that are in /utils/workflow, however, are only intended to be used by workflows. As we would not expect AST to already be installed on the runner, there doesn't seem to be a need to add a Pester test for that. If we moved this function up into /utils, then I think your idea would be smart.

Can you think of any other (non-workflow) code that would want to use the Install-AzureSignTool function?