Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write unit tests for build and sign release #1521

Open
wants to merge 62 commits into
base: main
Choose a base branch
from

Conversation

james-garriss
Copy link
Collaborator

🗣 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.

@james-garriss james-garriss self-assigned this Jan 17, 2025
@james-garriss james-garriss added enhancement This issue or pull request will add new or improve existing functionality infrastructure Related to configuring infrastructure necessary for the project labels Jan 17, 2025
Comment on lines 13 to 19
# Note: This is NOT the ACTUAL release version for ScubaGear.
# That value is found in ScubaGear.psd1.
# This is only used for things like the release file name.
# Yes, this is a disconnect that violates DRY.
version:
description: "Release Version (e.g., 1.2.4)"
required: true
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

regex

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines 3 to 8
BeforeDiscovery {
$ScriptPath = Join-Path -Path $PSScriptRoot -ChildPath '../../utils/workflow/Install-AzureSignTool.ps1' -Resolve
# Source the function
. $ScriptPath
Install-AzureSignTool
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

@schrolla schrolla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good functionally, but recommend some style and comment updates. See below.

.github/workflows/publish_private_package.yaml Outdated Show resolved Hide resolved
.github/workflows/publish_private_package.yaml Outdated Show resolved Hide resolved
.github/workflows/publish_public_package.yaml Outdated Show resolved Hide resolved
.github/workflows/publish_public_package.yaml Outdated Show resolved Hide resolved
Testing/workflow/Build-SignRelease.Tests.ps1 Outdated Show resolved Hide resolved
Testing/workflow/Install-AzureSignTool.Tests.ps1 Outdated Show resolved Hide resolved
Testing/workflow/Build-SignRelease.Tests.ps1 Outdated Show resolved Hide resolved
dotnet --version
dotnet tool install --global AzureSignTool --version 5.0.0
# OIDC Login to Azure Public Cloud with AzPowershell (enableAzPSSession true)
# Source the function
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is unnecessary as it just restates in plain english what the next line does using standard PowerShell syntax.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More pain and suffering.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment still present. Recommend removing entirely.

.github/workflows/build_sign_release.yaml Outdated Show resolved Hide resolved
Comment on lines +18 to +31
param(
[Parameter(Mandatory = $true)]
[string]
$AzureKeyVaultUrl,
[Parameter(Mandatory = $true)]
[string]
$CertificateName,
[Parameter(Mandatory = $true)]
[string]
$ReleaseVersion,
[Parameter(Mandatory = $true)]
[string]
$RootFolderName
)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recommend aligning parameters at same indent level for style consistency.

Suggested change
param(
[Parameter(Mandatory = $true)]
[string]
$AzureKeyVaultUrl,
[Parameter(Mandatory = $true)]
[string]
$CertificateName,
[Parameter(Mandatory = $true)]
[string]
$ReleaseVersion,
[Parameter(Mandatory = $true)]
[string]
$RootFolderName
)
param(
[Parameter(Mandatory = $true)]
[string]
$AzureKeyVaultUrl,
[Parameter(Mandatory = $true)]
[string]
$CertificateName,
[Parameter(Mandatory = $true)]
[string]
$ReleaseVersion,
[Parameter(Mandatory = $true)]
[string]
$RootFolderName
)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am confused by this one, b/c they already are aligned. Maybe you are just seeing some weird formatting on GitHub?

image

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@james-garriss It's because the first two params use tabs and the latter use spaces. You're IDE lines them up because you have tabstops set to 2, but GitHub has it set to 2. For consistency with style guide, recommend changing so all of the parameters (and all indents) convert tabs to spaces.

Copy link
Collaborator

@schrolla schrolla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Functionally all good. Saw one missed comment removal and convert tabs to spaces in one spot. But nothing to hold things up. Would recommend addressing before merge though.

dotnet --version
dotnet tool install --global AzureSignTool --version 5.0.0
# OIDC Login to Azure Public Cloud with AzPowershell (enableAzPSSession true)
# Source the function
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment still present. Recommend removing entirely.

@james-garriss james-garriss added this to the Lionfish milestone Jan 30, 2025
@james-garriss james-garriss requested a review from buidav January 30, 2025 18:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This issue or pull request will add new or improve existing functionality infrastructure Related to configuring infrastructure necessary for the project
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Write unit tests for build and sign release
3 participants