Unless noted in the YAML, these are all licensed under the root folder's MIT license.
- Reusable GitHub Actions Workflows
- GitHub Actions
- GitHub Tokens
- Versioning
- .NET
- .NET/NPM
- NPM
- Examples
- Sequence Diagrams
- calculate-version-with-npm-version-using-pr-labels.yml
- extract-version-from-npm-package-json.yml
- npm-build.yml
- npm-create-version-tag.yml
- npm-pack.yml
- npm-packages-pr-build.yml
- npm-packages-pr-create-tag.yml
- npm-packages-release-on-tag.yml
- npm-publish-to-github-packages.yml
- npm-publish-to-myget.yml
- npm-test.yml
Create a GitHub release using an existing tag, then attach a file from the runner artifact to the release. This only supports a single artifact file.
Given a list of branch names, verifies that the tag exists on one or more of those branch names. This helps guard against someone pushing a tag to another branch on the repo in cases where you can't restrict who can push tags. Or you just want to guard against someone pushing a version tag to the wrong branch.
Generates a GITHUB_TOKEN from a GitHub Application registered for the organization. The list of requested permissions can be customized.
Notes:
-
Because of how GitHub takes efforts to protect GitHub Tokens from being passed between jobs, we have to encrypt/obfuscate the token. Doing this in a separate job is still useful because it limits exposure of the GitHub App's private key to just this job runner. The other job steps which consume the token have no way to request a higher level set of permissions.
-
As late as Aug 2023, GitHub App tokens can NOT be used to access GitHub Packages.
Calculates the version using a version.txt file and GitHub "github.run_id" value. This will increment the patch value roughly every 15 minutes.
Scripts for executing the dotnet build / test / pack / publish cycle. These workflows run in separate GitHub Action jobs. Doing it this way will increase your GitHub Actions minutes consumption rate but provides the ability to do things in parallel and quickly see which part of the build failed.
We may provide consolidated variants in the future which use fewer separate jobs.
Build the solution using dotnet build. The workspace is then persisted into a short-lived artifact and the NuGet packages are cached for later build steps.
Using the persisted workspace and cached packages from the build step, run dotnet test against the solution. It produces a test results artifact in the 'trx' format.
Use dotnet pack to create .[s]nupkg files for all projects in the solution which have <IsPackable>true</IsPackable> (which is the default). Projects that should not be packed should set that to false in the .csproj file.
Package up a single project directory into a ZIP file that an be deployed to Azure Web Apps.
Workflows that are useful when you have a .NET application with a JavaScript front-end that can be built/tested with npm run build / npm run test steps.
Build the solution using dotnet build against the solution and run npm run build in a single project folder. The workspace is then persisted into a short-lived artifact and the NuGet/NPM packages are cached for later build steps.
Using the persisted workspace and cached packages from the build step, run dotnet test against the solution and run npm run test in a single project folder. It produces a dotnet test results artifact in the 'trx' format.
There is no way to skip test running. If you have no NPM tests, and won't be adding any, set the 'test' script in package.json to the no-op "exit 0".
Scripts for executing the NPM build / test / pack cycle. These workflows run in separate GitHub Action jobs. Doing it this way will increase your GitHub Actions minutes consumption rate but provides the ability to do things in parallel and quickly see which part of the build failed.
We may provide consolidated variants in the future which use fewer separate jobs.
Each box is a separate job within the GitHub Actions workflow.
flowchart LR
version["Calculate Version
(Use PR Labels)"]
build["NPM Build"]
test["NPM Test"]
pack["NPM Pack"]
build --> test
test --> pack
version --> pack
flowchart LR
version["Calculate Version
(Use PR Labels)"]
build["NPM Build"]
test["NPM Test"]
pack["NPM Pack"]
build --> test
test --> pack
version --> pack
generate-token["Generate Token"]
generate-token --> create-tag
create-tag["Create Tag"]
version --> create-tag
pack --> create-tag
flowchart LR
verify-tag["Verify that tag
is on correct
branch."]
verify-tag --> version
verify-tag --> build
version["Extract Version
(package.json)"]
build["NPM Build"]
test["NPM Test"]
pack["NPM Pack"]
build --> test
test --> pack
version --> pack
pack --> publish-myget["MyGet"]
pack --> publish-github["GitHub"]
pack --> publish-npm["NPM"]
pack --> release-notes["Create Release Notes"]
Calculate the version by starting with an NPM package.json file and then looking at labels applied to the pull request (PR). Once the version is calculated this workflow returns ouput variables that can be used in later jobs. There is support for package.json files that are named otherwise or do not exist at the root of the repository.
Extract the version from the NPM package.json file. Once the version is extracted this workflow returns ouput variables that can be used in later jobs. There is support for package.json files that are named otherwise or do not exist at the root of the repository.
Execute 'npm run build' against the package.json file. There is support for package.json files that are named otherwise or do not exist at the root of the repository. This workflow only runs the build script.
At the end of the job, it bundles up the entire workspace into a .tgz file for use in later jobs. This reduces the amount of time needed to run tests, security scans, or the 'npm pack' command later on.
The disadvantage of separate jobs is cost. You are billed a minimum of one minute of runtime for every job in a workflow. But the advantage is the ability to perform job steps in parallel (such as tests) and process isolation.
Executes npm version in a way that creates a git commit and also tags that commit. The only file that should change during this step is the 'package.json' file. The commit and tag are then pushed to the main git repo for future use by other PRs.
There is support for package.json files that are named otherwise or do not exist at the root of the repository.
Requires the use of a GitHub App token in order to perform the push. This is because we need to bypass any branch protection and/or rulesets on the branch.
Execute npm pack against the package.json file. There is support for package.json files that are named otherwise or do not exist at the root of the repository. This workflow only runs the pack command.
The resulting artifact (a .tgz file) will be uploaded to the workflow run and output variables provide information on the archive name (artifact_name) and file path (artifact_file_path).
Designed to be called when a PR is opened against a branch in the repository. This operates with a read-only GitHub Token for safety. See the PR Build Sequence diagram.
Designed to be called when a PR is merged against a branch in the repository. It creates a new commit and tag using the a GitHub App token upon completion. See the PR Merge Sequence diagram.
Designed to be called when a tag is created on a specific branch in the repository. Tags which are not created on the correct branch will result in workflow failure. See the Release on Tag Sequence diagram.
Publish the NPM package to the GitHub Packages registry. The artifact (.tgz) file is pulled from the artifacts on the workflow run.
Publish the NPM package to the MyGet NPM registry. The artifact (.tgz) file is pulled from the artifacts on the workflow run.
Execute 'npm run test' against the package.json file. There is support for package.json files that are named otherwise or do not exist at the root of the repository. This workflow only runs the test script.
Note: This restores the workspace created in the npm-build.yml job before executing the test script.