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 3 times, most recently from 9a3479d to 265f3c4 Compare September 16, 2025 20:53
@refi64 refi64 force-pushed the wip/refi64/cli branch 2 times, most recently from 4e086ae to 0a83feb Compare October 7, 2025 22:09
refi64 added 4 commits October 7, 2025 17:12
This is largely just a rename, as well as the slightly-silly
`obo-test-support` crate that exists to be depended on by `obo-core`
*and* `obs-gitlab-runner`.
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.
@refi64 refi64 force-pushed the wip/refi64/cli branch 2 times, most recently from f54be9c to 7130e19 Compare October 7, 2025 22:30
This adds a new crate `obo-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.
This splits the single readme into three, a top-level one with all the
useful shared info, and much smaller project-specific ones with the
relevant setup.
@refi64
Copy link
Collaborator Author

refi64 commented Oct 23, 2025

Fixed some minor issues (typos + wasn't actually using timeouts when running commands in the tests) and pushed up accidentally-missing commits.

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.

2 participants