.github's Introduction

nodenv GitHub Workflows

This repository houses reusable workflows for the nodenv organization. It also contains starter workflows (templates) for calling these reusable workflows.

Versioning

The reusable workflows attempt to adhere to SemVer with the release tags. For convenience, each tagged release will also advance the corresponding "major version" branch. e.g. Tagging a release like v2.5.0 will fast-forward the v2 branch to the latest 2.x tag. This way consumers of these reusable workflows may "soft-pin" to a major version and automatically get minor and patch updates. see Contributing#releasing

.github's People

Contributors

Watchers

.github's Issues

Downgrade action permissions

Should be using minimal permissions necessary in all the workflows these actions use.

release.yml #12 and 1d615ae
sync-default-branch
tag-major
test

org-level public profile from this readme

https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile

https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/managing-your-profile-readme

add vN branch protections

templates need categories

Add version-bumping workflow (ala node-build)

want to be able to trigger a release via github UI or cli without running npm version locally.

also means we need to get nodenv-bot gpg signing to work in the workflow.

Add OSSF scorecard workflow

https://github.com/marketplace/actions/ossf-scorecard-action

Switch tag-major workflow to push a tag instead of a branch

At first, I balked at github's insistence to continually force-push and rewrite tags. Common understanding of tags is that they are effectively permanent. However, the distinction from branches is very fine (particularly for lightweight tags).

And switching to push tags is more in-line with their intended purpose. Further, once vY is pushed, vX effectively becomes a dead branch, but shouldn't be deleted. So we'd rather keep the major-version tags as tags (still lightweight). That way the special branches don't get deleted; they appear on github's UI along with the full version tags; and we're more clear about their purpose.