chore: track script to make local test images

[willmurphyscode]

Can be used for local development. Might be worth integrating into npm commands.

Remembering to start the local registry before running tests locally is cumbersome. Here's a shell script, copied essential from the docs, to do it for us.

Questions:

1. Should this script be instead moved to an npm target?
2. Should this script be extracted from test setup into its own task?
3. How should we handle failure modes, e.g. where there's already a container named registry or a port is in use?
4. Should we totally dispense with the local registry and just push test images to a container registry somewhere?

PR is a conversation starter, in other words. But this script has been kicking around locally for a while and I use it, so I wanted to share.

[wagoodman]

Should we totally dispense with the local registry and just push test images to a container registry somewhere?

this would require that local development requires non local resources for testing, which isn't ideal

Should this script be instead moved to an npm target?

yes -- I think the idiomatic way to deal with stuff like this is as a new script entry here

sbom-action/package.json

Line 7 in 72370e1

"scripts": {

Should this script be extracted from test setup into its own task?

can it be both? That is, have the test automatically set it up if its not already running, or use an already running one?

How should we handle failure modes, e.g. where there's already a container named registry or a port is in use?

My vote would be to name it sbom-action-registry with a unique-enough static port (so probably not 5000) and always use it (if already created then use that)

[kzantow]

Questions:

Should this script be instead moved to an npm target?

This should be integrated into the tests so running npm test does any required setup. This can be done with before/after hooks: https://jestjs.io/docs/setup-teardown#one-time-setup

Should this script be extracted from test setup into its own task?

No, it should be integrated with the tests.

How should we handle failure modes, e.g. where there's already a container named registry or a port is in use?

Fail the tests.

Should we totally dispense with the local registry and just push test images to a container registry somewhere?

This would be a fine solution, too -- it could be a GHCR package linked to this repo.

[willmurphyscode]

It sounds like consensus is to move startup code from

sbom-action/.github/workflows/test.yml

Lines 68 to 73 in 72370e1

	- name: Build images
	run: |
	for distro in alpine centos debian; do
	docker build -t localhost:5000/match-coverage/$distro ./tests/fixtures/image-$distro-match-coverage
	docker push localhost:5000/match-coverage/${distro}:latest
	done

to a target in

sbom-action/package.json

Line 7 in 72370e1

"scripts": {

It might be nice to go further and make npm test call the new functionality, but that has a bit of difficulty:

1. A developer wants to run npm test on every code change
2. A developer needs to run npm run start-test-registry (or whatever we call it) only if the images change / once per session, which is way less often than item 1.

Therefore, for npm test to also start the test registry, we'd need to make starting the test registry idempotent, which in turn would be annoying because then someone would have to restart the test registry if they changed an image file.

I'll see how hard it is to make an npm run start-test-registry command idempotent, and failing that at least add it as a script and document it.

[kzantow]

These images are not really ever changing, the main purpose was just to validate that the command is actually running and generating files and that the output isn't changing drastically. I strongly favor just pushing these images to GHCR and updating the tests to point to them.

[willmurphyscode]

I strongly favor just pushing these images to GHCR and updating the tests to point to them.

This is the way, but that's a totally different approach, so just closing this for now.