Skip to content

Conversation

refi64
Copy link
Collaborator

@refi64 refi64 commented Aug 29, 2025

As usual, only new commit is the last one. Only thing missing is README edits, because i'd like an OK on the general structure before I write out all the details.

@refi64 refi64 force-pushed the wip/refi64/cli branch 2 times, most recently from 91b7c15 to 9a3479d Compare September 16, 2025 13:51
Passing around `self` risks confusing the borrow checker if we need to
invoke a method on a field, and it's rather confusing to begin with.
All the generic command handling is now part of an `actions` module, and
logging happens through a rather cursed magic bridge in the new
`logging` module to remove the widespread use of outputln.
This is largely just a rename, as well as the slightly-silly
`obs-commander-test-support` crate that exists to avoid making the
primary `obs-commander` crate depend on testing dependencies.
Most of this logic is rather intricate and shareable between multiple
implementations, so it makes sense for them to be in a separate crate.
This necessitates quite a bit of refactoring of the test structure so
that the shared test code can actually run commands and inspect the
logs + artifacts. Since there are various somewhat strange requirements
around command execution (i.e. needing to use timeouts but still get the
result), that API was redone around a builder trait, which also makes it
easy for implementation-specific tests to have their own methods on it.
External services like GH Actions can read JSON but *not* YAML, and the
previous format couldn't simply be written "as JSON" because it relied on
having structs as keys. This tweaks the format to be JSON-friendly and
uses actual JSON files.
There are cases where we get the files from places that are irrelevant
to the shared artifacts code, so those callers need to be able to still
place the AsyncFiles inside the wrappers.
This adds a new crate `obs-commander-cli` that behaves much like the
commands already available to the runner, but as a separate entity. As
replacement for child pipeline generation, the `generate-monitor`
command will create a JSON table containing the commands needed to run
monitoring and download binaries for a given repo/arch combination.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant