Explore different ways to retrieve the list of repositories

[oscard0m]

Right now octoherd supports the following type of arguments when passing the --repositories argument:

• One or multiple repositories in the form of 'repo-owner/repo-name'
• 'repo-owner/*' will find all repositories for one owner
• '*' will find all repositories the user has access to.

In some cases, a user may want to run an octoherd script over a concrete subset of repositories under certain condition/s:

• All the repositories a user has starred (original discussion here)
• All the repositories of a certain org/user containing a topic, using a certain language, containing a certain collaborator... (and other multiple queries you can imagine)

Would make sense to extend octoherd's CLI to support other sources to get this list of respositories?

[oscard0m]

One of the solutions @gr2m propose is the following:

$ my-script-to-retrieve-repositories | npx @octoherd/script-star-or-unstar --unstar

Originally posted here

[oscard0m]

I think this solution would work and it would unblock users with this kind of needs but I would like to arrive to a solution where Octoherd's CLI can get those lists.

@gr2m What do you think about this:

• Extend --octoherd-repos option to support a script path (the same way --octoherd-script is doing).
• When the option received is a script path, execute it and get the output as the list of repositories to apply the script. (⚠️ not sure on how to differentiate paths from ${user}/${repo})
• Keep giving support for list of repos as strings or patterns.

[gr2m]

I'm worried about the added complexity this will result in. I don't think the current use case is strong enough to grant the added complexity.

If you want to define a custom script anyway, why not piping using |? It's the unix way

[oscard0m]

I'm worried about the added complexity this will result in. I don't think the current use case is strong enough to grant the added complexity.

Yes, that's why I have this mixed feelings about going for it.

If you want to define a custom script anyway, why not piping using |? It's the unix way

It's a bit long to type but not a big deal of course. Actually, octoherd supporting pipe is a good sign the CLI is well designed. What "concerns" me is that these scripts are falling apart from Octoher's script ecosystem so we are losing:

• Losing track these scripts exist. Something we were solving with the other octoherd scripts.
• Losing all the boilerplate and other benefits from create-octoherd-script.

Not sure if we should "release" a new GitHub topic for these kind of octoherd scripts so they are on the radar. And if we should consider updating create-ocotherd-script for covering this.

[gr2m]

You make good points :) I'll let it sink in