Implement CI/CD through GitHub Actions

[aleks-ivanov]

The pipeline runs:

1. CI

• automated Semantic Version GitHub tag bumping
• projects build and packaging
• unit tests
• uploading of packages as pipeline artifacts

2. CD

• publishing to NuGet
• automated GitHub Release with asset attachment

Full transparency, the pipeline is the product of a lot of best guessing based on limited information, 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 🙂

Resolves #579

[darrelmiller]

I would love to be able to use this, but unfortunately, as these packages are published as Nuget packages with the Microsoft.* prefix, they need to be codesigned with a Microsoft cert. I do not believe this is currently possible via a GitHub action.

[aleks-ivanov]

@darrelmiller we have dealt with a similar case where an Appxbundle was required to be signed for upload to the Microsoft App Store.

Here's how we did it:

1. Locally, the owner's *.pfx key is converted to BASE64
2. In the remote, the resulting code is stored as a GitHub secret
3. During the run of the pipeline, from the secret a *.pfx key is generated
4. The *.pfx key is used during the build step to sign the bundle

As far as we understand, the signing of a NuGet package is done practically the same way (the difference being the key format), so we think the same solution can be applied.

Do you think this would be an appropriate solution in this case ?

[baywet]

@aleks-ivanov thanks for putting this together.
To give you more insights about the sign-in process, we don't have access to the certificates. This is done via ADO tasks that contact a central sign-in server. Last time I checked, it wasn't available for GitHub actions which is a shame.

@darrelmiller I suggest we still keep this, but we disable the part that uploads binaries as build artefacts and as release assets. Because we'd still get:

• build
• test
• tag
• create release

Which is already super valuable on its own.
Whenever the sign-in tasks are available for github actions, we can reenable the upload steps here and add the sign-in ones before those + add a nuget publish step and we'll have the full story on github actions.

[baywet]

this task is deprecated, consider replacing by something else.

[baywet]

this task is deprecated, consider replacing by something else.

[baywet]

this task is deprecated, consider replacing by something else.

[aleks-ivanov]

@baywet

On the last commit we commented out all lines of code that are connect to the NuGet package publish to the gallery and as pipeline artifacts, and replaced the deprecated release actions with the one suggested by its maintainers. Also commented out the lines of code that attach the NuGet packages to the automatically created release.

[baywet]

ping @darrelmiller for merge

[darrelmiller]

@baywet We now have Azure Pipeline YAML that does the signing. We should chat about whether these two separate pipelines could be complementary.

[baywet]

GitHub actions are nice in the sense that people get an exact copy of they clone. Non-msft also have access to the log when it fails allowing them to investigate on their own if they break it. All of that without needing to learn/create an account for Azure DevOps.
I think we should keep the CI part of that workflow then. Thoughts?

[baywet]

@darrelmiller I don't believe the ADO pipeline is currently creating github releases, I believe we should create github releases to communicate changes, tag our codebase and provide a clear line of sight to people using the library without requiring them to go over to nuget. Do you know if creating the release will be added to the ADO pipeline? (if yes we should remove that part from the current PR, if not we should keep it)