Skip to content

Conversation

jpartlow
Copy link
Contributor

@jpartlow jpartlow commented Sep 9, 2025

Sane defaults for beaker options, os matrices and vms definitions are
currently duplicated in the various
project/.github/workflows/acceptance.yml workflows, and in the
openvoxproject/acceptance-pipelines/.github/workflows/openvox_acceptance_pipeline.yml,
and would be duplicated again as I work out a build_and_test.yml
pipeline that would also call into beaker_acceptance.yml

This patch pulls all of these fairly static defaults into
beaker_acceptance.yml and selects the correct set based on the give
project-name. This way the callers can just provide the project-name,
ref, and key inputs like versions, unless they really need to fiddle
with beaker for their particular run.


The project-name input used to be synonymous with the actual repository
containing the test suite to execute. But since the separate
openvox-agent repository was deprecated and pushed into
openvox/packaging, that no longer applies, and we have two test suites
inside the openvox repository, openvox/acceptance (the openvox test
suite) and openvox/packaging/acceptance (the openvox-agent test suite)
that we need to be able to execute.

This commit changes project-name to suite-name, and tracks the actual
repository as a default selected with the rest of the defaults
associated with suite-name.

Sane defaults for beaker options, os matrices and vms definitions are
currently duplicated in the various
project/.github/workflows/acceptance.yml workflows, and in the
openvoxproject/acceptance-pipelines/.github/workflows/openvox_acceptance_pipeline.yml,
and would be duplicated again as I work out a build_and_test.yml
pipeline that would also call into beaker_acceptance.yml

This patch pulls all of these fairly static defaults into
beaker_acceptance.yml and selects the correct set based on the give
project-name. This way the callers can just provide the project-name,
ref, and key inputs like versions, unless they really need to fiddle
with beaker for their particular run.
In a callable workflow a boolean input that isn't given will be false,
making it impossible to differentiate between the caller didn't pass a
value (so we should supply a default), versus the caller explicitly
passed false and we should respect that.

To work around this, switched install-openvox-server and
install-openvoxdb to type string, so we can handle them, and then use
fromJson to get the boolean value again from the outputs used by the rest
of the workflow.
There isn't a strong case for the caller needing to modify any of these.
The project-name input used to be synonymous with the actual repository
containing the test suite to execute. But since the separate
openvox-agent repository was deprecated and pushed into
openvox/packaging, that no longer applies, and we have two test suites
inside the openvox repository, openvox/acceptance (the openvox test
suite) and openvox/packaging/acceptance (the openvox-agent test suite)
that we need to be able to execute.

This commit changes project-name to suite-name, and tracks the actual
repository as a default selected with the rest of the defaults
associated with suite-name.
@jpartlow jpartlow force-pushed the provide-acceptance-defaults-by-project branch from 1586ec9 to 1c79f7a Compare September 9, 2025 19:53
@jpartlow jpartlow marked this pull request as ready for review September 9, 2025 20:12
@jpartlow
Copy link
Contributor Author

jpartlow commented Sep 9, 2025

@jpartlow jpartlow merged commit 3bbf00f into OpenVoxProject:main Sep 9, 2025
@jpartlow jpartlow deleted the provide-acceptance-defaults-by-project branch September 9, 2025 20:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants