kinsondigital / cicd Goto Github PK
View Code? Open in Web Editor NEWA NUKE driven CICD system for building and releasing KinsonDigital projects
License: MIT License
A NUKE driven CICD system for building and releasing KinsonDigital projects
License: MIT License
🚀Preview Release
label to this issue.🚀Preview Release
workflow).Reasons for local unit test execution:
The version can be updated by setting the values of the <Version/>
and <FileVersion/>
XML tags in the project file.
The <Version/>
and <FileVersion/>
values can hold production and preview releases.
The <AssemblyVersion/>
XML tag can only hold production values. Preview values are not aloud.
<!--Preview Release Example-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
<AssemblyVersion>1.2.3</AssemblyVersion>
By default, the release notes go into a ReleaseNotes folder inside of the Documentation folder with the Documentation folder at the root of the repository.
Preview release notes path: ./Documentation/ReleaseNotes/PreviewReleases.
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Changes such as release notes and version updates should be committed to the destination branch (preview/v#.#.#-preview.#) in the pull request attached to this issue.
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>
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
🚀Preview Release
label to this issue.🚀Preview Release
workflow).Reasons for local unit test execution:
The version can be updated by setting the values of the <Version/>
and <FileVersion/>
XML tags in the project file.
The <Version/>
and <FileVersion/>
values can hold production and preview releases.
The <AssemblyVersion/>
XML tag can only hold production values. Preview values are not aloud.
<!--Preview Release Example-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
<AssemblyVersion>1.2.3</AssemblyVersion>
By default, the release notes go into a ReleaseNotes folder inside of the Documentation folder with the Documentation folder at the root of the repository.
Preview release notes path: ./Documentation/ReleaseNotes/PreviewReleases.
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Changes such as release notes and version updates should be committed to the destination branch (preview/v#.#.#-preview.#) in the pull request attached to this issue.
Create unit tests for the following extension methods:
AddIndents()
AddNewLine()
ToSnakeCase()
ToPascalCase()
ToKebabCase()
IsUpperCase()
ToLowerCase()
method unit tests createdLogRequirementTitle()
method unit tests createdCreateDuplicateCharacters()
method unit tests createdCapitalizeWords()
method unit tests createdToSpaceDelimitedSections()
method unit tests createdIsProductionVersion()
method unit tests createdNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
unit-test-status-check.yml
workflow template is generatedNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
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.
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
GetProdMilestoneDescription()
method renamed to CreateMilestoneDescription()
ReleaseType
added to the methodNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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
README.md
file<ApplicationIcon/>
elementPackageIcon/>
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Set up the NuGet package metadata to include licensing.
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
GitRepoService
-
✨new feature
Commit
property addedBranch
property addedGitHubActions
object created -
✨new feature
GitHubActionsService
.Token
property added.Actor
property added.
GitHubActions
object. If local, use the currently logged in user name.Ref
property added.BaseRef
property added.
HeadRef
property added.
GitHubActions.HeadRef
. If local, use the current branch.PullRequestNumber
property added.
GitHubActions
object.No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
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;
}
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Create unit tests for the following extension methods:
FileVersionExists()
AssemblyVersionExists()
GetVersion()
GetFileVersion()
GetAssemblyVersion()
GetReleaseNotesAsLines()
FileVersionExists()
method unit tests createdAssemblyVersionExists()
method unit tests createdGetVersion()
method unit tests createdGetFileVersion()
method unit tests createdGetAssemblyVersion()
method unit tests createdGetReleaseNotesAsLines()
method unit tests createdNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
🚀Preview Release
label to this issue.🚀Preview Release
workflow).Reasons for local unit test execution:
The version can be updated by setting the values of the <Version/>
and <FileVersion/>
XML tags in the project file.
<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
The release notes go into the appropriate folder:
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Changes such as release notes and version updates should be committed to the same source branch in the pull request attached to this issue.
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:
Solution (NUKE)
object manually like the GitRepository (NUKE)
object.
SolutionService
createdReactable
's to be used to get the NUKE Solution
object into the serviceNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Create unit tests for the following extension methods:
IsReleaseToDoIssue()
IsReleasePullRequest()
LogAsError()
LogAsInfo()
BuildReleaseNotesFilePath()
GetReleaseNotes()
IsReleaseToDoIssue()
method unit tests createdIsReleasePullRequest()
method unit tests createdLogAsError()
method unit tests createdLogAsInfo()
method unit tests createdBuildReleaseNotesFilePath()
method unit tests createdGetReleaseNotes()
method unit tests createdNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
🚀Preview Release
label to this issue.🚀Preview Release
workflow).Reasons for local unit test execution:
The version can be updated by setting the values of the <Version/>
and <FileVersion/>
XML tags in the project file.
<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
The release notes go into the appropriate folder:
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Changes such as release notes and version updates should be committed to the same source branch in the pull request attached to this issue.
Create unit tests for the following extension methods:
IsMasterBranch()
IsDevelopBranch()
IsFeatureBranch()
IsPreviewBranch()
IsReleaseBranch()
IsPreviewFeatureBranch()
IsMasterBranch()
method unit tests createdIsDevelopBranch()
method unit tests createdIsFeatureBranch()
method unit tests createdIsPreviewBranch()
method unit tests createdIsReleaseBranch()
method unit tests createdIsPreviewFeatureBranch()
method unit tests createdNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Initial project release
🚀Preview Release
label to this issue.🚀Preview Release
workflow).Reasons for local unit test execution:
The version can be updated by setting the values of the <Version/>
and <FileVersion/>
XML tags in the project file.
<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
The release notes go into the appropriate folder:
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Changes such as release notes and version updates should be committed to the same source branch in the pull request attached to this issue.
Create unit tests for the following extension methods:
ReleaseExists()
MilestoneExists()
GetByTitle()
GetHtmlUrl()
CloseMilestone()
UpdateMilestoneDescription()
UploadTextFileAsset()
GetLogText()
- This is overloaded. Create tests for both.
ReleaseExists()
method unit tests createdMilestoneExists()
method unit tests createdGetByTitle()
method unit tests createdGetHtmlUrl()
method unit tests createdCloseMilestone()
method unit tests createdUpdateMilestoneDescription()
method unit tests createdUploadTextFileAsset()
method unit tests createdGetLogText()
method unit tests created for both overloadsNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.");
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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"
}
Owner
field name to RepoOwner
and refactor to a private
propertyMainProjName
field name to RepoName
and refactor to a private
propertyNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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:
The requirement check to add is ThatThePRIsAssignedToMilestone()
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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 bool
s. 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.
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.
Or()
method implementedGetValue()
method implementedNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
🚀Preview Release
label to this issue.🚀Preview Release
workflow).Reasons for local unit test execution:
The version can be updated by setting the values of the <Version/>
and <FileVersion/>
XML tags in the project file.
<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
The release notes go into the appropriate folder:
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Changes such as release notes and version updates should be committed to the same source branch in the pull request attached to this issue.
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.
internal
, is set to internal
sealed
should be set to sealed
.No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Create unit tests for the following extension methods:
PrintErrors()
EqualTo()
RepositoryName()
IssuesForMilestone()
PullRequestsForMilestone()
TagExists()
PrintErrors()
method unit tests createdEqualTo()
method unit tests createdRepositoryName()
method unit tests createdIssuesForMilestone()
method unit tests createdPullRequestsForMilestone()
method unit tests createdTagExists()
method unit tests createdNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Create the exceptions below:
MissingVersionException
MissingFileVersionException
MissingVersionException
createdMissingFileVersionException
createdExtensionsMethods.cs
fileNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
🚀Preview Release
label to this issue.🚀Preview Release
workflow).Reasons for local unit test execution:
The version can be updated by setting the values of the <Version/>
and <FileVersion/>
XML tags in the project file.
<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
The release notes go into the appropriate folder:
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Changes such as release notes and version updates should be committed to the same source branch in the pull request attached to this issue.
🚀Preview Release
label to this issue.🚀Preview Release
workflow).Reasons for local unit test execution:
The version can be updated by setting the values of the <Version/>
and <FileVersion/>
XML tags in the project file.
<!--Syntax for preview releases-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
The release notes go into the appropriate folder:
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Changes such as release notes and version updates should be committed to the same source branch in the pull request attached to this issue.
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.
PreviewReleaseNotesDirName
createdProductionReleaseNotesDirName
createdReleaseNotesBaseDirPath
is converted to a NUKE param
PreviewReleaseNotesDirPath
prop refactored to not be static and to use the ReleaseNotesBaseDirPath
and PreviewReleaseNotesDirName
properties to construct the path.
PreviewReleaseDirName
to construct the pathProductionReleaseNotesDirPath
prop refactored to not be static and to use the ReleaseNotesBaseDirPath
and ProductionReleaseNotesDirName
properties to construct the path.Requires()
methods to check for null or empty.No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Adjust the logging of information for the ThatTheProjectVersionsAreValid()
requirement method.
Refer to the image below for more info:
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
🚀Preview Release
label to this issue.🚀Preview Release
workflow).Reasons for local unit test execution:
The version can be updated by setting the values of the <Version/>
and <FileVersion/>
XML tags in the project file.
The <Version/>
and <FileVersion/>
values can hold production and preview releases.
The <AssemblyVersion/>
XML tag can only hold production values. Preview values are not aloud.
<!--Preview Release Example-->
<Version>1.2.3-preview.4</Version>
<FileVersion>1.2.3-preview.4</FileVersion>
<AssemblyVersion>1.2.3</AssemblyVersion>
By default, the release notes go into a ReleaseNotes folder inside of the Documentation folder with the Documentation folder at the root of the repository.
Preview release notes path: ./Documentation/ReleaseNotes/PreviewReleases.
Release note file names must follow a particular syntax and are in markdown format so they can be added to the release.
Changes such as release notes and version updates should be committed to the destination branch (preview/v#.#.#-preview.#) in the pull request attached to this issue.
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);
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
MilestoneService
created.No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Create unit tests for the following extension methods:
IsHotFixBranch()
GetBranchType()
HasCorrectVersionSyntax()
HasCorrectFileVersionSyntax()
HasCorrectAssemblyVersionSyntax()
VersionExists()
IsHotFixBranch()
method unit tests createdGetBranchType()
method unit tests createdHasCorrectVersionSyntax()
method unit tests createdHasCorrectFileVersionSyntax()
method unit tests createdHasCorrectAssemblyVersionSyntax()
method unit tests createdVersionExists()
method unit tests createdNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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:
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.
No response
This issue is finished when:
No response
No response
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Review and fix documentation throughout codebase. This includes fixing spelling and/or grammatical errors in .md files and code docs
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
SecretService
to build the path correctly.SecretService
unit tests updatedICurrentDireService
interface deletedCurrentDireService
class deletedNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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
InternalsVisibleTo
attributes moved.No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Create unit tests for the following extension methods:
IssueExists()
HasLabels()
for pull requests clientExists()
LabelExists()
IsAssigned()
HasLabels()
for issues clientIssueExists()
method unit tests createdHasLabels()
method unit tests created for the pull requests client overloadExists()
method unit tests createdLabelExists()
method unit tests createdIsAssigned()
method unit tests createdHasLabels()
method unit tests created for the issues client overloadNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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 }}
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
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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();
ThatAllOfTheReleaseMilestoneIssuesAreClosed()
requirement method fixedThatAllOfTheReleaseMilestonePullRequestsAreClosed()
requirement method fixedNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
No response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
Create unit tests for the following extension methods:
IsPreviewVersion()
ExtractBranchVersion()
ContainsNumbers()
DoesNotContainNumbers()
IsOnCorrectBranch()
IsCorrectBranch()
IsPreviewVersion()
method unit tests createdExtractBranchVersion()
method unit tests createdContainsNumbers()
method unit tests createdDoesNotContainNumbers()
method unit tests createdIsOnCorrectBranch()
method unit tests createdIsCorrectBranch()
method unit tests createdNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
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.
LoadSecretsService
changes
System.IO.Abstractions
LoadSecretsService
classGitHubClientService
serviceGitHubClient
from a private static
field to a private
property with a getter
GitHubClientService
service to get the clientLoadSecretsService
name refactored to SecretService
var
and param
names to appropriate namesNo response
No response
Change Type | Label |
---|---|
Bug Fixes | 🐛bug |
Breaking Changes | 🧨breaking changes |
New Feature | ✨new feature |
Workflow Changes | workflow |
Code Doc Changes | 🗒️documentation/code |
Product Doc Changes | 📝documentation/product |
Priority Type | Label |
---|---|
Low Priority | low priority |
Medium Priority | medium priority |
High Priority | high priority |
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.