-
Notifications
You must be signed in to change notification settings - Fork 7
programmatic interface #219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
one potential complication i'm seeing as i look at extracting this is the
this appears to be specifically added in the octoherd specific octokit. this works in the current cli context because it specifically uses that octokit. do we want to require that specific octokit be the one used when calling the programmatic interface? i admit that i don't fully have my head around the value that the what thoughts do you have about this detail? |
Logging for Octoherd is relevant for reports, which is not something I got to implement yet. But the idea is that Octoherd out of the box can do a structured log into a file, and then at the end run a reduce function that can present useful information. The idea I had was to support other exports beyond For logging, Octoherd's Octokit has an own internal plugin: https://github.com/octoherd/octokit/blob/1fd16014024039e79b0120ca4606f554b4a7cd04/octokit-plugins/logger.js I think for the programmatic interface we might not need to take any of this into account. I think just using a standard |
… a provided list of repositories for octoherd#219
… a provided list of repositories for #219
… a provided list of repositories for #219
this sounds really useful. interested to learn more about the goal at some point |
Discussed in #218
Originally posted by travi April 29, 2025
i've been finding myself wanting to accomplish similar goals to what the cli package does, but in non-terminal contexts. i really like the convention of the octoherd script taking an octokit instance, a repo, and maybe some options, but the herd part of the equation is limited to being used within the cli. i'm wondering if there would be value in exposing some of the core herd functionality as a programmatic interface, possibly as a separate package.
i think the primary logic is essentially
cli/lib/run-script-against-repositories.js
Lines 54 to 69 in ecc8f5b
the resolve-repositories logic could make sense as another function to expose, but that feels still a bit specific to the cli context in its current form.
in addition to the non-terminal context, exposing the core logic that expects an octokit instance and the list of normalized repos could be a way to enable alternative ways to determine the list of repos and support alternative auth options for octokit.
if this were available, that programmatic interface could enable other contexts beyond being from from a terminal, but would also enable embedding into other cli implementations. maybe this cli package becomes more of a reference implementation and easy default, but the programmatic interface is the path for more complex implementations?
The text was updated successfully, but these errors were encountered: