Add a production build action

[iBrotNano]

Requirements

Open Questions?

Nothing

Blockers

No blockers

Description

A build for the production branch must be implemented. For this branch the versions must be set without any suffixes. It is the branch wich targets the releases. Tags are only set when this branch is built because every commit to this branch is a release. The build should stored as a package.

Conditions

Commit from source. The branch should be startet from scratch after the implementation is done. This means I have to delete it after the implementation.

Side effects

No

Acceptance tests

1. A build must be startet if there is any commit to the branch production.
2. Versions don't have any suffixes.
3. A tag is automatically created when this branch is built.
4. No tag is created if any other branch is built.
5. A package is stored on any builds
6. The CHANGELOG.md should be used as the release information of the NuGet.
7. The status badge for the build of production is shown in README.md

Design

There is already a script build.yml. This should be the only place where a build is configured. With if: github.ref_name == 'production' a condition can be defined where all the necessary steps can be performed.

---

Info: https://docs.github.com/en/actions/learn-github-actions/contexts#github-context describes all conditions which can be checked.

---

This can be used to set the version number as needed or do branch specific tasks like setting a version tag.

https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts describes how artefacts can be stored.

https://docs.github.com/en/actions/publishing-packages/about-packaging-with-github-actions shows how to publish a package.

https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge#using-the-branch-parameter describes how to set a status badge for the build.

https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry documents the GitHub NuGet Repository which can be used as a store for this project.

Dissection

Integration test	1
Action	A test commit to production must be made to check if a build starts.
Expected result	A build starts and finished successfully.

Integration test	2
Action	The version of the NuGet must be checked.
Expected result	The version has the format x.x.x without any suffixes.

Integration test	3
Action	Check Github for tags.
Expected result	A tag for the created version present.

Integration test	4
Action	Build any other branch and check the tags in GitHub.
Expected result	No tag is created for the build.

Integration test	5
Action	Build any other branch and check GitHub Packages for a new NuGet.
Expected result	The NuGet built is stored in GitHub Packages.

Integration test	6
Action	Build production and check GitHub Packages for a new NuGet.
Expected result	The NuGet built is stored in GitHub Packages.

Integration test	7
Action	Check the NuGet's release information with the NuGet Package Explorer.
Expected result	The changelog is used as the NuGet's release information.

Integration test	8
Action	Check README.md for the status badge of production.
Expected result	The state of the build of production is shown as a status badge in README.md.

Development

TODOs

• Create a feature branch if needed (Maybe configuration changes or new project files)
• Update the dependencies
• Create a branch production
• Start a build during a pull request
• Set versions without any suffixes for production builds
• Set version tags for produtcion builds
• Don't set version tags for any other build
• Use ony <Major>.<Minor>.<Patch> as version number
• Upload the NuGet of the build as artefacts
• What documentation should be uploaded as artefacts? (Docs)
• Is there a way to upload multiple artefacts in one step?
• Upload documentation files of the build as artefacts
• Store the NuGet
• Create a release only for production builds
• Resolve the conflict in feat(#8): Added files and documentation to the release. #33
• Add information about the download location of the NuGet to the release
• Modify the release template for GitHub about publishing the release draft
• Use the CHANGELOG.md as release information of the NuGet
• Store the documentation of production builds with the NuGets
• Create a release in GitHub for builds of production
• The version is not set in CHANGELOG.md
• Is it possible to clean up the GitHub NuGet Repository automatically?
• Cleanup old packages during build for features, bugfixes, PRs, release-branch-builds and main builds.
• Check if the exception handling is well done
• Check if further tests must be written
• Write meaningful comments
• Are there any compiler warnings?
• Do all unit tests pass?
• Is the version number correctly configured?
• Remove the production branch used for development
• Remove the dev tags
• Remove the dev release

Notes

Expressions can be combined with operators described at https://docs.github.com/en/actions/learn-github-actions/expressions.

There is some documentation generated for a build. These documents are:

• README.md
• CHANGELOG.md

---

Note: https://github.com/actions/upload-artifact describes how to upload artefacts in multiple ways.

---

https://dev.to/j_sakamoto/writing-a-nuget-package-release-notes-in-an-outside-of-a-csproj-file-3f94 shows how to read the release notes from a file.

There is an action to delete old packages.

---

Note: https://github.com/actions/delete-package-versions

---

I will implement the following policy for NuGet package deletion:

• feature builds: All but the current build.
• bugfix builds: All but the current build.
• release builds: All but the current build.
• PRs: All but the current build.
• main builds: All but the current build.
• No production builds.

---

Note: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/errors-warnings shows how to configure the warning behaviour of MSBuild.

---

Debug

• Create a branch production for testing

ID	Result	Pass
1	A build starts.	🟢

ID	Result	Pass
2	The version has the correct format.	🟢

ID	Result	Pass
3	The tag for the version is created.	🟢

ID	Result	Pass
4	For other branches are no tags created.	🟢

ID	Result	Pass
5	A pre-release package is stored in the NuGet repo.	🟢

ID	Result	Pass
6	A release NuGet is stored in the NuGet repo.	🟢

ID	Result	Pass
7	The changelog is used as release information in the NuGet.	🟢

ID	Result	Pass
8	The state is shown.	🟢

• Delete production after the tests are done
• Cleanup all releases, tags and packages

Documentation

• Do I need a new PIA or update an existing one?
• Update the README.md
• Update the CHANGELOG.md
• Describe the setup of the story if needed for end users
• Does something in the wiki needed to be updated? 🔴
• Needs other stuff been documented? 🔴

Decisions

Decision	Cause
I only use <Major>.<Minor>.<Patch> as version for tags.	It is much more readable. The build number is more important if problems happen because someone forget to increase the version number.
I don't deploy the NuGet with this issue.	I will do it later in an own issue because it will have organisational effort.
I will store the NuGet in GitHubs NuGet Repository.	I can use GitHubs own repository to store all kinds of builds like feature and master ones. Not only production build which should be published to nuget.org.
I will create a release on GitHub for build of production.	Through those releases I can download a defined release of the project.
I will use Conventional Commits to write commit massages from now on.	To follow a standard which allows to build tools on it.
I will create release drafts instead of releases.	This ensures that no release is published accidently. I need to prove it first.
I will write the release notes by myself.	It is effort. It needs discipline. It makes it possible to write more meaningful content and use it in all build steps happening before the release.
I will use the content of CHANGELOG.md as the description of the NuGet.	It is used from GitHub to display information about a NuGet.
I will change the template of the CHANGELOG.md.	To fit the heading of the generated release notes.
I disabled warnings completely for the examples.	The error list is more readable.

PIAs

☠

Links

• https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
• https://docs.github.com/en/actions/deployment/about-deployments/about-continuous-deployment
• https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
• https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases
• https://docs.github.com/en/actions/publishing-packages/about-packaging-with-github-actions
• https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge#using-the-branch-parameter
• https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry
• https://docs.github.com/en/actions/learn-github-actions/expressions
• https://github.com/actions/upload-artifact
• https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-nuget-registry
• https://docs.github.com/en/packages/learn-github-packages/viewing-packages
• https://www.conventionalcommits.org/en/v1.0.0/
• https://github.com/softprops/action-gh-release
• https://dev.to/j_sakamoto/writing-a-nuget-package-release-notes-in-an-outside-of-a-csproj-file-3f94
• https://github.com/actions/delete-package-versions
• https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/errors-warnings

Demo

• Setup a fresh demo environment
• Do tests
• Remove the branch production
• Remove the tags, releases and NuGets.

All acceptance tests pass.

Deployment

• Merge feature into master with a squash and remove the feature branch (Feature/#8 #37)
• Check if the compiled artifact is valid
• Cleanup the Git history locally on the dev system