kinsondigital / cicd Goto Github PK

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Problem:
Currently, getting pull request branch information will only work by using the GitHubActions.HeadRef or GitHubActions.BaseRef. Using this is only good in the GitHub environment because that is the only time the GitHubActions instance is NOT NULL.
This means that running pull request-related stuff locally becomes an issue because the object instance is null.

Solution:
To allow this functionality to work, create a service that will detect if the build is a server build or a local build. If it is a server build, use the GitHubActions instance, if it is a local build, use the GitHubClient to interact with the API to be able to get the branch information required.

To maximize the testability of the new service, create a thin wrapper around the GitHubActions object that can be injected into the new service for use. This way we are not found to server only state and can easily maximize our testability.

Once the new service is complete, refactor the use cases throughout the code base to use the new service instead of the GitHubActions object.

Acceptance Criteria

• Create service GitRepoService - ✨new feature New feature that does not exist
  • Commit property added
  • Branch property added
• Create service GitHubActions object created - ✨new feature New feature that does not exist
  • Name of service should be GitHubActionsService.
  • Token property added.
  • Actor property added.
    • If on the server, just GitHubActions object. If local, use the currently logged in user name.
  • Ref property added.
  • BaseRef property added.
    • Needs to be nullable as well as explain with code docs that it is only used on the server.
  • HeadRef property added.
    • If on the server, use the GitHubActions.HeadRef. If local, use the current branch.
  • PullRequestNumber property added.
    • Needs to be nullable as well as explain with code docs that it is only used on the server.
  • Refactor code throughout the code base to use the new service instead of the raw GitHubActions object.

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Adjust the logging of information for the ThatTheProjectVersionsAreValid() requirement method.

Refer to the image below for more info:

Acceptance Criteria

• Console log of version information adjusted

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Issues Released

• #33
• #35
• #36

Perform Release ToDo List

• Release PR linked to this issue.
• Add 🚀Preview Release label to this issue.
• All issues listed in the Issues Released section above.
• All issues in the Issues Released section are closed and all issue tasks are complete.
• All unit tests have been executed locally and have passed. (Check out the appropriate release branch before running tests).
• Version in project file updated (All changes made directly on the release branch).
• Release notes created and added (All changes made directly on the release branch).
• Manual QA Testing completed (if applicable).
• Pull request has been approved and merged into a release branch before performing the release. (Releases are performed on preview branches).
• Release to preview complete. (The release is performed by running the 🚀Preview Release workflow).

Post-Release ToDo List

• The GitHub release has been created and is correct.
• If applicable, the NuGet package has been successfully deployed to nuget.org.
• Announcement of release on Twitter verified (if applicable). (Announcement should be performed automatically with the release).
• Announcement has been pushed to the Discord channel.

Additional Information:

<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>

Code of Conduct

• I agree to follow this project's Code of Conduct

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create a new service called BranchValidatorService. This new service will provide everything related to validating branches. This will check if a branch has valid syntax, check if an issue number in a branch exists, check if the branch is a correct branch type using a delegate, etc.

Reason:
Implementing this will greatly improve testability as well as flexibility. If the branching model needs to be changed, then this can happen.

This service will need to inject whatever is required for it to do its job. Also, this should be a fluent API with OR and AND logic.
This means that there should be 2 methods named And() and Or().

There also should be a Reset() method that resets the state of everything for service reuse. Since the service will be a singleton, this means that the state can carry over. Implement a GetResult() method to return the result of the validation process.
The service needs to reset its validation state internally when the GetResult() method is called. This will make sure that the state is not carried over to other parts of the build system when it is reused.

And Or Logic Implementation:
This should be accomplished by having 2 arrays in the service.
Fist Array (AND list): One array will hold a list of bool values that will be ANDED together.
Second Array (OR list): The second array will consist of a list of bool lists. Each item will be a list of bools. Every time Or() is invoked, the current AND snapshot of bool items will be copied to the OR list and the AND list will be cleared out. Once GetValue() is invoked, the OR list can be processed to get an end result of type bool the entire process.

⚠️This logic will have to be thoroughly tested!!

Go through the code base and look for this validating type functionality and implement it into the new service.
Once it is all finished, the code throughout the project can be refactored to use the new validator service.

A great place to look for this kind of required validation is in the ExtensionsMethods.cs file.

Acceptance Criteria

• Service Created
  • Or() method implemented
  • GetValue() method implemented
  • Fluent API implemented throughout
  • Units test thoroughly test implementation and all pass

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create a target that shows the current version when it is executed.

This is to simply help understand what version of the CICD system is being used which can also help for debugging purposes when testing in CICDTest.

Acceptance Criteria

• Show version target added

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Currently the GitHubTokenService is not working correctly. The token service uses the SecretService to load the GitHub token locally from disk when running locally. The issue is that the SecretService is looking in the wrong location.

How it is supposed to work:
It is supposed to look inside of the .github folder in the root of the repository. If the folder directory path exists, it should check for the local-secrets.json file and load the token from the file.

How it currently working:
It uses the .github folder as part of the path, but the section before the .github folder in the path is incorrect. It is building the beginning section of the path based on the execution path of the assembly. This is how it was originally designed, but the ⚽ was dropped and somebody forgot to update the service. (That somebody was "me". 😁

How To Fix It:
Instead of using the executable assembly, use the Directory.GetCurrentDirectory() instead to build the path section before the .github folder. This represents the root of the repository. The SecretService uses the ICurrentDirService to be able to get the executing assembly. This is only used in the SecretService class. Just delete the ICurrentDirService interface and CurrentDirService class entirely. It is not needed anymore.

Acceptance Criteria

• Refactor the SecretService to build the path correctly.
• SecretService unit tests updated
• ICurrentDireService interface deleted
• CurrentDireService class deleted

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

When detecting open pull requests in a milestone and when the detection should skip release todo issues & pull requests, the issue or pull request is detected anyways when it should not. This is a simple fix. The boolean value and comparison logic should be changed to the setup below.

ThatAllOfTheReleaseMilestoneIssuesAreClosed() Requirement Method:

        var openMilestoneIssues = GitHubClient.Issue.IssuesForMilestone(RepoOwner, RepoName, projectVersion)
            .Result
-            .Where(i => (skipReleaseToDoIssues || i.IsReleaseToDoIssue(releaseType)) && i.State == ItemState.Open).ToArray();
+            .Where(i => (skipReleaseToDoIssues is false && i.IsReleaseToDoIssue(releaseType)) && i.State == ItemState.Open).ToArray();

ThatAllOfTheReleaseMilestonePullRequestsAreClosed() Requirement Method:

        var openMilestonePullRequests = GitHubClient.Issue.PullRequestsForMilestone(RepoOwner, RepoName, $"v{projectVersion}")
            .Result
-            .Where(i => (skipReleaseToDoPullRequests || i.IsReleasePullRequest(releaseType)) && i.State == ItemState.Open).ToArray();
+            .Where(i => (skipReleaseToDoPullRequests is false && i.IsReleasePullRequest(releaseType)) && i.State == ItemState.Open).ToArray();

Acceptance Criteria

• ThatAllOfTheReleaseMilestoneIssuesAreClosed() requirement method fixed
• ThatAllOfTheReleaseMilestonePullRequestsAreClosed() requirement method fixed

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create the exceptions below:
MissingVersionException
MissingFileVersionException

Acceptance Criteria

• Custom exception named MissingVersionException created
• Custom exception named MissingFileVersionException created
• TODO items have been removed from the ExtensionsMethods.cs file
• Unit tests created

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Convert the 'Owner' and 'MainProjNamefields to private properties that are marked as a NUKE[Parameter]. Refactor the name of the 'Owner field (which is being converted into a prop) to RepoOwner.
Refactor the name of the MainProjName field (which is being converted into a prop) to RepoName.

Also, add the correct parameters and values in the ~/.nuke/parametes.json file like below.

{
  "$schema": "./build.schema.json",
  "Solution": "CICD.sln",
  "RepoOwner": "KinsonDigital",
  "RepoName": "CICD"
}

Acceptance Criteria

• Refactor the Owner field name to RepoOwner and refactor to a private property
• Refactor the MainProjName field name to RepoName and refactor to a private property

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Currently, the location of release notes is located in the Documentation folder. There is also a hard-coded release notes dir name field named ReleaseNotesDirName. The field is used to construct the dir path of where the release notes are located. This path construction depends on the documentation dir path to get access to the release notes for some of the NUKE targets.

There is also a static property of type AbsolutePath that is the directory path of where the release notes are located. Convert this property to a NUKE parameter. This is going to mean that the path could possibly not be set up in the ~.nuke/parameters.json file which means that it will be null or empty when the target is executed. So the targets that use this new NUKE param property will have to check if it is null or empty.

Create a Requires() method that can be used to check that the release notes dir path is not null or empty. This is just in case something went wrong in the path construction. Find all of the targets that use the release notes pathing and setup a requires that use the new method to check.

Convert the static prop ReleaseNotesBaseDirPath to a NUKE parameter. This will be the base path of where the preview and production releases will live.

Acceptance Criteria

• New NUKE param prop named PreviewReleaseNotesDirName created
• New NUKE param prop named ProductionReleaseNotesDirName created
• The static prop ReleaseNotesBaseDirPath is converted to a NUKE param
  • This is the location where the preview and production release note directories will reside
• PreviewReleaseNotesDirPath prop refactored to not be static and to use the ReleaseNotesBaseDirPath and PreviewReleaseNotesDirName properties to construct the path.
  • This will use the new PreviewReleaseDirName to construct the path
• ProductionReleaseNotesDirPath prop refactored to not be static and to use the ReleaseNotesBaseDirPath and ProductionReleaseNotesDirName properties to construct the path.
• Targets that require the release notes using the new Requires() methods to check for null or empty.

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Remove the project named SampleProject from the solution.

This project is pretty much empty and is not being used. It was originally going to be used for local testing but things changed.

Acceptance Criteria

• SampleProject removed from solution

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Currently, there is only one method to create the custom milestone description for preview and production releases.

The name of the method implies that it is only for production but it's implementation actually only is for preview. This needs to be fixed. Also, the implementation needs to be improved and refactored to be used for both.

To do this, add a ReleaseType parameter to the method and dynamically perform what is required based on this param value.
Once finished, the method also needs to be used in the preview release target.

Acceptance Criteria

• The GetProdMilestoneDescription() method renamed to CreateMilestoneDescription()
• Parameter of type ReleaseType added to the method
• Method refactored for better variables names as well as to work for both types of releases

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

When running a pull request build on the server, the build status check target is reporting that the pull request number is 0. This is not the case.

This is occurring in the ThatThePullRquestExists() requirement method. Further investigation shows that the logic in this method is incorrect and needs to be changed. Currently it checks the local build PullRequestNumber build parameter value AND is using this value to check if the pull request exists as long as the value of it is not 0.

This will not work because the PullRequestNumber is only for local builds, and is always 0 with server builds. This means the result is always 0 so it fails. Basically, this method is only setup for local builds, not local AND server builds.

Rewrite the method to work for both occasions.

Other Info:

Here is the link to the 🪲Debugging Workflow action run where the bug occurred.

File CICD.Requirements.cs

 private bool ThatThePullRequestExists()
    {
        nameof(ThatThePullRequestExists)
            .LogRequirementTitle("Checking if the pull request number exists.");
                               👇🏼This line here is the problem.👇🏼
        var result = PullRequestNumber != 0 && GitHubClient.PullRequest.Exists(RepoOwner, RepoName, PullRequestNumber).Result;

        if (result)
        {
            Console.WriteLine($"{Environment.NewLine}{ConsoleTab}The pull request number '{PullRequestNumber}' exists.");
            return true;
        }

        Log.Error($"The pull request number '{PullRequestNumber}' does not exist.");
        Assert.Fail("Pull request failure.");
        return false;
    }

Acceptance Criteria

• Requirement method rewritten to work for server builds.

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

An error is thrown when trying to get the pull request number for a target when the run is not a pull request run.

Here is the link to the CICDTest to the 🪲Debuggin Workflow run of when the error occurred.

Error Screenshot:

More Information:
In the GitHubActionsService class, the PullRequestNumber property gets the pull request number from either the pull request number value sent in via the CLI during local builds or from the GitHubActions.Instance.PullRequestNumber property during server builds.

The problem is when running a server run that is not a pull request. For example, manual execution using the workflow_dispatch event. Because the run is not a pull request run, their is no pull request data available. Internally in the property, NUKE is using JObject to get the pull request data from some JSON data. But since that data is not available, it explodes. 💥

To fix this, make a change in the GitHubActionsService.PullRequestNumber property. Just first check to see if the build is a server build. If so, use the GitHubActions.Instance.PullRequestNumber value. If not, return null.

Acceptance Criteria

• Bug fixed

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create a new service to wrap up all of the NUKE solution functionality that is currently being used. This will help increase testability which will eventually enable tests to be written for the build system.

The service is going to require an instance of the Solution from NUKE to exist inside the service so the service can do its job.

Things To Consider:

1. Currently there is no way to manually create a Solution (NUKE) object manually like the GitRepository (NUKE) object.
   • This means that we need to find a way to get the solution object inside of the service. One way is to create an observable.
   • The service will be very light weight like a thin wrapper.

Acceptance Criteria

• SolutionService created
• Service added to IoC container
• Create the required Reactable's to be used to get the NUKE Solution object into the service
• Code refactored to use service

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Fix an issue where the project is not setup as a dotnet tool. This needs to be done in the csproj file and it simply not setup correctly.

Add the 2 XML elements below to the csproj file to fix the issue

<PackAsTool>true</PackAsTool>
<ToolCommandName>cicd</ToolCommandName>

Acceptance Criteria

• csproj setup correctly to behave as a dotnet tool

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

An exception is being thrown for the preview release target only for server runs.

This only occurs when getting the configuration for running unit tests and builds. This is due to how the branch is being detected when deciding if the build or test execution should be a Debug or Release run.

The exception is a Octokit NotFoundException. This is because the branch being used for configuration detection is the target branch of a pull request. The problem is that preview and production releases do not run off of a pull request event. They are executed manually. Due to this, the pull request number is 0 and this is the number used when trying to pull PR information using the GitHub API when using Octokit.

This fortunately is an easy fix. Refer to the fix below.

Located in the GetBuildConfig() method in the CICD.cs file.

- return PullRequestService.TargetBranch.IsMasterBranch()
+ return Repo.Branch.IsMasterBranch()
            ? Configuration.Release
            : Configuration.Debug;

This fix uses the repository service to figure out the currently checked-out branch instead of the pull request service which reaches out to GitHub to get PR data.

Acceptance Criteria

• Bug fixed

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create unit tests for the following extension methods:

• IssueExists()
• HasLabels() for pull requests client
• Exists()
• LabelExists()
• IsAssigned()
• HasLabels() for issues client

Acceptance Criteria

• Unit tests created for the following methods:
  • IssueExists() method unit tests created
  • HasLabels() method unit tests created for the pull requests client overload
  • Exists() method unit tests created
  • LabelExists() method unit tests created
  • IsAssigned() method unit tests created
  • HasLabels() method unit tests created for the issues client overload

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Move all [assembly: InternalsVisibleTo("", AllInternalsVisible = true)] attributes to the csproj file.

This can be done with the example below:

<ItemGroup>
  <InternalsVisibleTo Include="$(AssemblyName).Testing" />
</ItemGroup>

For more info on this if required, refer to this video

Acceptance Criteria

• InternalsVisibleTo attributes moved.

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create unit tests for the following extension methods:

• IsPreviewVersion()
• ExtractBranchVersion()
• ContainsNumbers()
• DoesNotContainNumbers()
• IsOnCorrectBranch()
• IsCorrectBranch()

Acceptance Criteria

• Unit tests created for the following methods:
  • IsPreviewVersion() method unit tests created
  • ExtractBranchVersion() method unit tests created
  • ContainsNumbers() method unit tests created
  • DoesNotContainNumbers() method unit tests created
  • IsOnCorrectBranch() method unit tests created
  • IsCorrectBranch() method unit tests created

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

When generating the workflow templates using the dotnet cicd GenerateWorkflows command, the unit-test-status-check.yml workflow template is not getting generated.

No errors are being thrown at all. It just simply is not working. The only theory I have is that the templates are being generated file by file alphabetically and this file is the last file. The file is probably somehow just being skipped due to the premature ending of the code.

Acceptance Criteria

• unit-test-status-check.yml workflow template is generated

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Issues Released

Initial project release

Perform Release ToDo List

• Release PR linked to this issue.
• Add 🚀Preview Release label to this issue.
• All issues listed in the Issues Released section above.
• All issues in the Issues Released section are closed and all issue tasks are complete.
• All unit tests have been executed locally and have passed. (Check out the appropriate release branch before running tests).
• Version in project file updated (All changes made directly on the release branch).
• Release notes created and added (All changes made directly on the release branch).
• Manual QA Testing completed (if applicable).
• Pull request has been approved and merged into a release branch before performing the release. (Releases are performed on preview branches).
• Release to preview complete. (The release is performed by running the 🚀Preview Release workflow).

Post-Release ToDo List

• The GitHub release has been created and is correct.
• If applicable, the NuGet package has been successfully deployed to nuget.org.
• Announcement of release on Twitter verified (if applicable). (Announcement should be performed automatically with the release).
• Announcement has been pushed to the Discord channel.

Additional Information:

<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>

Code of Conduct

• I agree to follow this project's Code of Conduct

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

For the PR status checks below, check that the PR is assigned to a milestone. When checking for a milestone, it needs to check for a milestone that is open. Closed milestones are considered to be already released.

PR Status Checks:

• FeaturePRStatusCheck
• PreviewFeaturePRStatusCheck
• HotFixPRStatusCheck

The requirement check to add is ThatThePRIsAssignedToMilestone()

Acceptance Criteria

• FeaturePRStatusCheck updated
• PreviewFeaturePRStatusCheck updated
• HotFixPRStatusCheck updated
• PrevReleasePRStatusCheck updated
• ProdReleasePRStatusCheck updated

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Currently, all of the workflow templates that can be generated for a project do not include a job step to restore the dotnet tool. Fix this by updating all of the workflow templates to include that extra step.

Workflow Changes:

name: ✅Build Status Check


+defaults:
+  run:
+    shell: pwsh


on:
  workflow_dispatch:
  pull_request:
    branches:
      - develop
      - preview/v*.*.*-preview.*
      - release/v*.*.*
      - master


jobs:
  build_project:
    name: Build Project
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
+    - name: Restore DotNet Tools
+      run: dotnet tool restore
    - name: Run Build Status Check
      run: dotnet cicd BuildStatusCheck
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Acceptance Criteria

• build-status-check.yml
• feature-pr-status-check.yml
• hotfix-pr-status-check.yml
• prev-feature-pr-status-check.yml
• prev-release-pr-status-check.yml
• prev-release.yml
• prod-release-pr-status-check.yml
• prod-release.yml

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Review and fix documentation throughout codebase. This includes fixing spelling and/or grammatical errors in .md files and code docs

Acceptance Criteria

• Documentation has been reviewed and fixed
• Code docs reviewed and fixed
• Update release notes for previous releases
  • For every release notes file that was changed, this is the release that needs to be updated.
  • ⚠️ Do not update release notes until the PR has been fully approved and merged!!!

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Issues Released

• #13
• #15
• #17
• #19

Perform Release ToDo List

• Release PR linked to this issue.
• Add 🚀Preview Release label to this issue.
• All issues listed in the Issues Released section above.
• All issues in the Issues Released section are closed and all issue tasks are complete.
• All unit tests have been executed locally and have passed. (Check out the appropriate release branch before running tests).
• Version in project file updated (All changes made directly on the release branch).
• Release notes created and added (All changes made directly on the release branch).
• Manual QA Testing completed (if applicable).
• Pull request has been approved and merged into a release branch before performing the release. (Releases are performed on preview branches).
• Release to preview complete. (The release is performed by running the 🚀Preview Release workflow).

Post-Release ToDo List

• The GitHub release has been created and is correct.
• If applicable, the NuGet package has been successfully deployed to nuget.org.
• Announcement of release on Twitter verified (if applicable). (Announcement should be performed automatically with the release).
• Announcement has been pushed to the Discord channel.

Additional Information:

<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>

Code of Conduct

• I agree to follow this project's Code of Conduct

Issues Released

• #27
• #53
• #65
• #67
• #69

Perform Release ToDo List

• All issues listed in the Issues Released section above.
• All issues in the Issues Released section are closed and all issue tasks are complete.
• Add 🚀Preview Release label to this issue.
• Issue is assigned to a project.
• Issue is assigned to a milestone.
• Release PR linked to this issue.
• All unit tests have been executed locally and have passed. (Check out the appropriate release branch before running tests).
• Version in project file updated (All changes made directly on the release branch (preview/v#.#.#-preview.#)).
• Release notes created and added (All changes made directly on the release branch (preview/v#.#.#-preview.#)).
• Manual QA Testing completed (if applicable).
• Pull request has been approved and merged into a release branch before performing the release. (Releases are performed on preview branches).
• Release to preview complete. (The release is performed by running the 🚀Preview Release workflow).

Post-Release ToDo List

• The GitHub release has been created and is correct.
• The NuGet package has been successfully deployed to nuget.org (if applicable).
• Announcement of release on Twitter verified (if applicable). (Announcement should be performed automatically with the release).
• Announcement has been pushed to the Discord channel (if applicable).

Additional Information:

<!--Preview Release Example-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
<AssemblyVersion>1.2.3</AssemblyVersion>

Code of Conduct

• I agree to follow this project's Code of Conduct

Complete The Item Below

• I have updated the title without removing the 🔬 emoji.

What To Research

Research how GraphQL works and how to use it. This is for the purpose of future enhancements on dealing with GitHub data and can help enhance the CICD project itself.

Resources:

• GraphQL Org
• GitHub GraphQL API

Create some examples that can be documented into this issue. Also try to use GraphQL in postman which will not only help learn about GraphQL, but also about using the GitHub GraphQL API.

Once this is all done and understood, create some issues to use the GraphQL API to add a feature to interact with the new project system to check if an issue or PR has been added to the project as well as possibly check which column it is in.

Another benefit is that once GraphQL is understood, workflows can be created to help automate some of the board flow.

Research Results

No response

Acceptance Criteria

This issue is finished when:

• Research complete and issues created (if needed).
• If any issues were created, they have been added to the Related Work section below.

ToDo Items

• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project.

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create unit tests for the following extension methods:

• FileVersionExists()
• AssemblyVersionExists()
• GetVersion()
• GetFileVersion()
• GetAssemblyVersion()
• GetReleaseNotesAsLines()

Acceptance Criteria

• Unit tests created for the following methods:
  • FileVersionExists() method unit tests created
  • AssemblyVersionExists() method unit tests created
  • GetVersion() method unit tests created
  • GetFileVersion() method unit tests created
  • GetAssemblyVersion() method unit tests created
  • GetReleaseNotesAsLines() method unit tests created

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Update the README file by changing the NOTICE!! section.
This section should be changed to explain that this project is for the KinsonDigital organization and is only maintained by the organizational members themselves.

Explain that we will not be taking outside contributions, but feature requests and bug reports are welcome.

Acceptance Criteria

• README file updated

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Se tup the project to properly be used as a dotnet tool. This will allow the project to be used for CICD operations easily as a dotnet tool by the rest of the organization's projects.

Acceptance Criteria

• Project properly setup as a dotnet tool
• Able to run a target to generate all of the required workflows
• Test project with unit tests created and setup to use the CICD project as a dotnet tool

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Issues Released

• #3

Perform Release ToDo List

• Release PR linked to this issue.
• Add 🚀Preview Release label to this issue.
• All issues listed in the Issues Released section above.
• All issues in the Issues Released section are closed and all issue tasks are complete.
• All unit tests have been executed locally and have passed. (Check out the appropriate release branch before running tests).
• Version in project file updated (All changes made directly on the release branch).
• Release notes created and added (All changes made directly on the release branch).
• Manual QA Testing completed (if applicable).
• Pull request has been approved and merged into a release branch before performing the release. (Releases are performed on preview branches).
• Release to preview complete. (The release is performed by running the 🚀Preview Release workflow).

Post-Release ToDo List

• The GitHub release has been created and is correct.
• If applicable, the NuGet package has been successfully deployed to nuget.org.
• Announcement of release on Twitter verified (if applicable). (Announcement should be performed automatically with the release).
• Announcement has been pushed to the Discord channel.

Additional Information:

<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>

Code of Conduct

• I agree to follow this project's Code of Conduct

Issues Released

• #55
• #59
• #60

Perform Release ToDo List

• All issues listed in the Issues Released section above.
• All issues in the Issues Released section are closed and all issue tasks are complete.
• Add 🚀Preview Release label to this issue.
• Issue is assigned to a project.
• Issue is assigned to a milestone.
• Release PR linked to this issue.
• All unit tests have been executed locally and have passed. (Check out the appropriate release branch before running tests).
• Version in project file updated (All changes made directly on the release branch (preview/v#.#.#-preview.#)).
• Release notes created and added (All changes made directly on the release branch (preview/v#.#.#-preview.#)).
• Manual QA Testing completed (if applicable).
• Pull request has been approved and merged into a release branch before performing the release. (Releases are performed on preview branches).
• Release to preview complete. (The release is performed by running the 🚀Preview Release workflow).

Post-Release ToDo List

• The GitHub release has been created and is correct.
• The NuGet package has been successfully deployed to nuget.org (if applicable).
• Announcement of release on Twitter verified (if applicable). (Announcement should be performed automatically with the release).
• Announcement has been pushed to the Discord channel (if applicable).

Additional Information:

<!--Preview Release Example-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
<AssemblyVersion>1.2.3</AssemblyVersion>

Code of Conduct

• I agree to follow this project's Code of Conduct

Issues Released

• #7
• #12
• #22
• #26

Perform Release ToDo List

• Release PR linked to this issue.
• Add 🚀Preview Release label to this issue.
• All issues listed in the Issues Released section above.
• All issues in the Issues Released section are closed and all issue tasks are complete.
• All unit tests have been executed locally and have passed. (Check out the appropriate release branch before running tests).
• Version in project file updated (All changes made directly on the release branch).
• Release notes created and added (All changes made directly on the release branch).
• Manual QA Testing completed (if applicable).
• Pull request has been approved and merged into a release branch before performing the release. (Releases are performed on preview branches).
• Release to preview complete. (The release is performed by running the 🚀Preview Release workflow).

Post-Release ToDo List

• The GitHub release has been created and is correct.
• If applicable, the NuGet package has been successfully deployed to nuget.org.
• Announcement of release on Twitter verified (if applicable). (Announcement should be performed automatically with the release).
• Announcement has been pushed to the Discord channel.

Additional Information:

<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>

Code of Conduct

• I agree to follow this project's Code of Conduct

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create unit tests for the following extension methods:

• IsHotFixBranch()
• GetBranchType()
• HasCorrectVersionSyntax()
• HasCorrectFileVersionSyntax()
• HasCorrectAssemblyVersionSyntax()
• VersionExists()

Acceptance Criteria

• Unit tests created for the following methods:
  • IsHotFixBranch() method unit tests created
  • GetBranchType() method unit tests created
  • HasCorrectVersionSyntax() method unit tests created
  • HasCorrectFileVersionSyntax() method unit tests created
  • HasCorrectAssemblyVersionSyntax() method unit tests created
  • VersionExists() method unit tests created

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Set up the NuGet package metadata to include licensing.

Packing a license file

Acceptance Criteria

• The project license is included as meta-data in the NuGet package

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

This is a build tool. Not a library meant for anybody to use to solve build problems. It is currently only for the KinsonDigital organization. Due to this, the code should be more hidden and closed off.

If the need arises in the future to expose or unseal anything for extension, it can be done then.

If the class can be internal, make it internal.
All classes should be sealed unless any inheritance is going on. But I do not think that is going on.

Acceptance Criteria

• All classes that should be internal, is set to internal
• All classes that are not sealed should be set to sealed.

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create unit tests for the following extension methods:

ReleaseExists()
MilestoneExists()
GetByTitle()
GetHtmlUrl()
CloseMilestone()
UpdateMilestoneDescription()
UploadTextFileAsset()
GetLogText() - This is overloaded. Create tests for both.

Acceptance Criteria

• Unit tests created for the following methods:
  • ReleaseExists() method unit tests created
  • MilestoneExists() method unit tests created
  • GetByTitle() method unit tests created
  • GetHtmlUrl() method unit tests created
  • CloseMilestone() method unit tests created
  • UpdateMilestoneDescription() method unit tests created
  • UploadTextFileAsset() method unit tests created
  • GetLogText() method unit tests created for both overloads

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create unit tests for the following extension methods:

• PrintErrors()
• EqualTo()
• RepositoryName()
• IssuesForMilestone()
• PullRequestsForMilestone()
• TagExists()

Acceptance Criteria

• Unit tests created for the following methods:
  • PrintErrors() method unit tests created
  • EqualTo() method unit tests created
  • RepositoryName() method unit tests created
  • IssuesForMilestone() method unit tests created
  • PullRequestsForMilestone() method unit tests created
  • TagExists() method unit tests created

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Issues Released

• #8

Perform Release ToDo List

• Release PR linked to this issue.
• Add 🚀Preview Release label to this issue.
• All issues listed in the Issues Released section above.
• All issues in the Issues Released section are closed and all issue tasks are complete.
• All unit tests have been executed locally and have passed. (Check out the appropriate release branch before running tests).
• Version in project file updated (All changes made directly on the release branch).
• Release notes created and added (All changes made directly on the release branch).
• Manual QA Testing completed (if applicable).
• Pull request has been approved and merged into a release branch before performing the release. (Releases are performed on preview branches).
• Release to preview complete. (The release is performed by running the 🚀Preview Release workflow).

Post-Release ToDo List

• The GitHub release has been created and is correct.
• If applicable, the NuGet package has been successfully deployed to nuget.org.
• Announcement of release on Twitter verified (if applicable). (Announcement should be performed automatically with the release).
• Announcement has been pushed to the Discord channel.

Additional Information:

<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>

Code of Conduct

• I agree to follow this project's Code of Conduct

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

In the ThatFeaturePRIssueHasLabel() requirement method, the main requirement method title and description are not properly printed to the console log.

Currently, it logs the name of the requirement method, which is correct. But the description of what the requirement method does is not correct.

Change To:

- .LogRequirementTitle($"Checking that the issue number in the '{branchTypeStr}' branch exists.");
+ .LogRequirementTitle($"Checking that the issue for the '{branchTypeStr}' branch contains at least one label.");

Acceptance Criteria

• Requirement method title and description logged to console has been fixed

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create a hotfix release target.

The target should be pretty close to the Production or Preview release targets. Pay close attention to the branch types as well as the release types when it comes to logic and checks.

Acceptance Criteria

• HotFix release target created

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Improve the GitHubClient setup and usage throughout the project.

Currently, the setup of the GitHubClient is not ideal when trying to make authorized GitHub API requests when running targets that use the GitHub API. To try and solve this issue, the LoadSecrestService was created to load a token to be used for setting up the GitHubClient for authorized requests. This needs to be put into use.

Create a new service called GitHubClientService that is used to create a GitHubClient object that is set up with a token for authorized requests. The new GitHubClientService will inject and use the LoadSecretsService to load the token from the disk.

The GitHubClientService and LoadSecretsService should also be set up with SimpleInjector so they can be easily consumed. The GitHubClientService should be set up in the IoC container as a singleton.

The GitHubClient property will be a readonly property that uses the GitHubClientService every time it is requested. The service will lazy load/create the internal client object/field. Every subsequent request into the service will check if the field is null and if it is not, simply return a reference of the field.

Acceptance Criteria

• LoadSecretsService changes
  • Create an interface for the service for setup for the IoC container
  • Refactor the main implementation code to be able to use System.IO.Abstractions
  • Create unit tests for the LoadSecretsService class
• Create new GitHubClientService service
• Convert the GitHubClient from a private static field to a private property with a getter
  • The getter will call out to the GitHubClientService service to get the client
• LoadSecretsService name refactored to SecretService
  • Refactor all var and param names to appropriate names
• If the loaded secret is null or empty, throw an exception

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create unit tests for the following extension methods:

• IsMasterBranch()
• IsDevelopBranch()
• IsFeatureBranch()
• IsPreviewBranch()
• IsReleaseBranch()
• IsPreviewFeatureBranch()

Acceptance Criteria

• Unit tests created for the following methods:
  • IsMasterBranch() method unit tests created
  • IsDevelopBranch() method unit tests created
  • IsFeatureBranch() method unit tests created
  • IsPreviewBranch() method unit tests created
  • IsReleaseBranch() method unit tests created
  • IsPreviewFeatureBranch() method unit tests created

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create a project logo. This logo should be the same as the KinsonDigital logo, but instead of { KD } in between the braces, add an up arrow in the center which represents shipping code/releases, and rotation arrows around the outside of the gear.

You could also put the arrows inside of the gear if there is room.

Once this is figured out, convert this into an application icon.

NuGet Setup:
Set up the NuGet package to use the icon. Make sure that the NuGet icon is packed into the package.

README:
Update the README.md file by adding the logo to the center and at the top

Acceptance Criteria

• Logo created
• Logo added to README.md file
• Application Icon set
  • This is the <ApplicationIcon/> element
• Icon
  • Added to project
  • Added to NuGet package
  • Package Icon set
    • This is the PackageIcon/>
  • Setup in csproj file

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

If the NuGet package does not exist because it has never been pushed to nuget.org, an HTTP status code of 404 (Not Found) will be thrown. This displays an obscure XML error that comes with the NuGet API when a package is not found.

Instead, add a try-catch that can check if the 404 error exists, and if so, simply return true.

This exists in the requirement method ThatTheNugetPackageDoesNotExist().

Changes To Implement:

        var projectVersion = project.GetVersion();

        var nugetService = new NugetDataService();
+       var packageVersions = Array.Empty<string>();

-       var packageVersions = nugetService.GetNugetVersions(RepoName).Result;
+       try
+       {
+           packageVersions = nugetService.GetNugetVersions("CICDTest").Result;
+       }
+       catch (HttpRequestException e)
+       {
+           if (e.StatusCode == HttpStatusCode.NotFound)
+           {
+               return true;
+           }
+       }

        var nugetPackageExists = packageVersions.Any(i => i == projectVersion);

Acceptance Criteria

• Try catch block added to look for 404 (Not Found) in the requirement method.
• Testing in CICDTest complete and working

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create unit tests for the following extension methods:

• IsReleaseToDoIssue()
• IsReleasePullRequest()
• LogAsError()
• LogAsInfo()
• BuildReleaseNotesFilePath()
• GetReleaseNotes()

Acceptance Criteria

• Unit tests created for the following methods:
  • IsReleaseToDoIssue() method unit tests created
  • IsReleasePullRequest() method unit tests created
  • LogAsError() method unit tests created
  • LogAsInfo() method unit tests created
  • BuildReleaseNotesFilePath() method unit tests created
  • GetReleaseNotes() method unit tests created

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Issues Released

• #42
• #43

Perform Release ToDo List

• All issues listed in the Issues Released section above.
• All issues in the Issues Released section are closed and all issue tasks are complete.
• Add 🚀Preview Release label to this issue.
• Issue is assigned to a project.
• Issue is assigned to a milestone.
• Release PR linked to this issue.
• All unit tests have been executed locally and have passed. (Check out the appropriate release branch before running tests).
• Version in project file updated (All changes made directly on the release branch (preview/v#.#.#-preview.#)).
• Release notes created and added (All changes made directly on the release branch (preview/v#.#.#-preview.#)).
• Manual QA Testing completed (if applicable).
• Pull request has been approved and merged into a release branch before performing the release. (Releases are performed on preview branches).
• Release to preview complete. (The release is performed by running the 🚀Preview Release workflow).

Post-Release ToDo List

• The GitHub release has been created and is correct.
• The NuGet package has been successfully deployed to nuget.org (if applicable).
• Announcement of release on Twitter verified (if applicable). (Announcement should be performed automatically with the release).
• Announcement has been pushed to the Discord channel (if applicable).

Additional Information:

<!--Preview Release Example-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
<AssemblyVersion>1.2.3</AssemblyVersion>

Code of Conduct

• I agree to follow this project's Code of Conduct

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create unit tests for the following extension methods:

• AddIndents()
• AddNewLine()
• ToSnakeCase()
• ToPascalCase()
• ToKebabCase()
• IsUpperCase()

Acceptance Criteria

• Unit tests created for the following methods:
  • ToLowerCase() method unit tests created
  • LogRequirementTitle() method unit tests created
  • CreateDuplicateCharacters() method unit tests created
  • CapitalizeWords() method unit tests created
  • ToSpaceDelimitedSections() method unit tests created
  • IsProductionVersion() method unit tests created

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.

Complete The Item Below

• I have updated the title without removing the 🚧 emoji.

Description

Create a new service named MilestoneService. This service will contain all of the required functionality that is required for milestones. This can all be found throughout the code base using the Octokit methods as well as all of the extension methods for the IMilestonesClient interface.

Build the service to provide all of the functionality that is used throughout the project. Unit tests should be created as well and all code should be refactored to use the service.

Also, the repo owner and name are required for a lot of this functionality due to the Octokit API. The service should have an IReactable<(string, string)> injected via the ctor so it can get the repo owner and name information for it to do its job.

Acceptance Criteria

• New service with the named MilestoneService created.
• Repo info reachable injected into the service for use.
• Unit tests created for the entire service

ToDo Items

• Change type labels added to this issue. Refer to the Change Type Labels section below.
• Priority label added to this issue. Refer to the Priority Type Labels section below.
• Issue linked to the correct project (if applicable).
• Issue linked to the correct milestone (if applicable).
• Draft pull request created and linked to this issue (only required with code changes).

Issue Dependencies

No response

Related Work

No response

Additional Information:

Code of Conduct

• I agree to follow this project's Code of Conduct.