-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automate build, publish and releases #146
Automate build, publish and releases #146
Conversation
This change set automates the build, test, package, and publish process for our .NET project using GitVersion to obtain the semantic version. The CD pipeline is triggered when a new release branch is created in the format of release/v{MAJOR.MINOR.PATCH}. It will publish a pre-release package to NuGet first, and only on approval will it publish the final version, create a tag that matches the version number, and generate the GitHub release with release notes. To ensure the version is calculated correctly, a tag was added to the previous commit that was released. The CD pipeline uses this tag to calculate the version number. The implementation details include: - Using GitVersion plugin to obtain the semantic version - Automating the build, test, package, and publish process - Creating a tag on the previous commit that was released to ensure correct version calculation - Publishing a pre-release package to NuGet first and only on approval publishing the final version, creating a tag that matches the version number, and generating the GitHub release with release notes - Create a pull request to ensure that any changes that were committed to the `release` branch is also merged back into `master` This change set simplifies the release process and ensures that all our artifacts are versioned correctly, making it easier for other developers to understand and track our what has changed in each release.
CONFIG REQUIRED PRIOR TO MERGE@TylerBrinks, this pull request includes changes to automate the build, test, package, and publish process for our GitHub project. I have implemented a release workflow with preview and release environments, allowing contributors to test and approve releases before they are published to NuGet. The following configuration changes have to be applied for the workflows to be executed successfully:
git tag v4.1.4 4e0d475
git push origin v4.1.4 |
@gdeswardt I think everything is configured. Please let me know if anything was missed. |
@TylerBrinks please can you create a tag and push it to the remote repository to mark version 4.1.4 so that the GitVersion plugin can automatically calculate the semantic version during each build? Here are the git commands for creating and pushing the tag git tag v4.1.4 4e0d475
git push origin v4.1.4 |
Thanks @TylerBrinks I have just accepted invitation to collaborate on this project. I will quickly push the tag and check the rest of the settings |
@TylerBrinks I have created a release branch and the pre-release version was published successfully to NuGet. Please can you review and if you are happy approve the release of version 4.2.0 on the workflow. This will automatically publish the release version to NuGet and get the release and changelog on the project, with a pull request that contains the changes that need to merge back into the master branch. https://github.com/TylerBrinks/ExCSS/actions/runs/4645817008 |
As per #140 this change set automates the build, test, package, and publish process for our .NET project using
GitVersion to obtain the semantic version.
The CD pipeline is triggered when a new release branch is created in the format of
release/v{MAJOR.MINOR.PATCH}
. It will publish a pre-release package to NuGet first, and only on approval will it publish the final version, create a tag that matches the version number, and generate the GitHub release with release notes.To ensure the version is calculated correctly, a tag was added to the previous commit that was released. The CD pipeline uses this tag to calculate the version number.
The implementation details include:
release
branch are also merged back into themaster
This change set simplifies the release process and ensures that all our artifacts are versioned correctly, making it easier for other developers to understand and track what has changed in each release.