Resolves: Consolidate current pipelines into a single pipeline with additional features

[szlatkow]

The pipeline runs:

1. CI

• projects build
• unit tests

2. CD

• publishing to NuGet

With this contribution, we consolidate the current pipelines into a single pipeline, so please let us know if anything could be done better and/or if any other automation is required by the project! We would be happy to improve it to satisfactory completion 🙂

In addition, the following features might be of value to the project and if you agree, we will be happy to add them to the pipeline:

• automated Semantic versioning
• publishing pipeline artifacts
• automated GitHub Release publish

Resolves #77

[ardalis]

I'm interested in how automatic semantic versioning would work and in GitHub Release publishing. What would that involve / look like? Related question: how do I configure the version as part of this proposed process? Do I just need to be sure to update it in the csproj file(s)? Last question: what if I make a commit that shouldn't be deployed, like an update to a comment or README file? How is that handled/controlled?

[szlatkow]

Hi @ardalis, The automatic Semantic Versioning step checks if there is a certain prefix semver label (fix, feat or perf) in the message of the push commit that triggered the workflow, it takes the last GitHub tag, creates a new tag depending on the prefix label in the commit message and pushes it to the repo's GitHub tags. (this step is independent of the .csproj files)

Example(fix/PATCH): git commit -a -m "fix: this is a PATCH release triggering commit" git push origin master

Result: v1.2.3 -> v1.2.4

If there is no prefix label in the commit message the tag generator does not create a new tag.

Do I just need to be sure to update it in the csproj file(s)?

The new version created by the automatic Semantic Versioning step can be applied to the .csproj file during the execution of the pipeline, to be used in the package creation.

Last question: what if I make a commit that shouldn't be deployed, like an update to a comment or README file? How is that handled/controlled?

Currently, in the CD job (which is executed on every push commit) there is a step called "Filter changes" that looks at the two project folders, detects changes and determines which one or both projects should be packaged and deployed to NuGet. In case there is automated Semantic Versioning, the execution of any deployment (which would be in the CD job) is handled by the automatic Semantic Versioning step. If a commit is pushed without a semver label in the message (e.g. a push commit that doesn't include changes to project itself and therefor a versioning change is not necessary), the CD job where the NuGet packages and GitHub release publishing are, is not executed.

For an example of automatic versioning, checkout this short video presentation about our contribution to the Notepads project.

[ardalis]

You mentioned docs - where are the docs on this?

The automatic Semantic Versioning step checks if there is a certain prefix semver label (fix, feat or perf) in the message of the push commit that triggered the workflow, it takes the last GitHub tag, creates a new tag depending on the prefix label in the commit message and pushes it to the repo's GitHub tags. (this step is independent of the .csproj files)

Example(fix/PATCH): git commit -a -m "fix: this is a PATCH release triggering commit" git push origin master

Result: v1.2.3 -> v1.2.4

If there is no prefix label in the commit message the tag generator does not create a new tag.