#Totally, I'm picturing replacing a
crude gate
that's how we're using it internally and we even run C/I against the task defintion in CONTRIBUTING.md
$ runme list
NAME FILE FIRST COMMAND DESCRIPTION NAMED
configureNPM CONTRIBUTING.md npm config set @buf:registry https://buf.build/gen/npm/v1 make sure to configure your local npm to pull from Buf's registry (for GRPC dependencies. Yes
setup CONTRIBUTING.md export GITHUB_REF_NAME=$(git branch --show-current) then ensure to install all project dependencies. Note GitHub token is required to auto-dowload the latest runme binary. The branch ref name is optional, if it's not main pre-release binaries are being considered. Yes
npm-watch CONTRIBUTING.md npm run watch Then just run the watcher and you're off to the races. Yes
build CONTRIBUTING.md export NODE_OPTIONS="--experimental-specifier-resolution=node --max-old-space-size=8192" To compile all extension files, run. Yes
bundle CONTRIBUTING.md export NODE_OPTIONS="--experimental-specifier-resolution=node --max-old-space-size=8192" And then package the extension into a .vsix file. Yes
[...]
woven rivet
Nice! If you create a dagger module for runme we would only need a single dagger cli dependency 🙂
crude gate
i'll definitely do that as part of migrating off GHA
crude gate
meant to reply not start a thread :-D. all this Slack brain damage haunting me.
sand kiln
I like deep threads fwiw.
I'm curious if the contributing notebook should include (possibly the same criteria) as pytest or nox/tox assertions, so that they can be included in CI ?
crude gate
Probably depends on the complexity of what's in your "instructions"
For an instance where complexity is high, we did continuously integrate Linkerd's Getting Started guide as a proof of concept:
it made sense to use an existing k8s assertion framework instead of encoding pre-/post-conditions in the markdown, @sand kiln
however, for simple things... e.g. a linter or go build something lower effort and less heavy handed would be entirely possible.