Allow bypassing repository resolve step

[stefanbuck]

Recently I was using Octoherd to archive 800+ repositories. While the script was running, I realized that Octoherd first resolves all the repositories to populate the repository argument in the script function

export async function script(octokit, repository, options) {
  // do something here
}

In this particular use-case of archiving repositories there was not need to read any data from the provided repository argument. I could may have used it to figure out if a repository is already archived or not, but the script was smart enough to fail gracefully in this case. Therefore resolving all repositories upfront was just a unnecessary step and use of time and rate limits.

Proposal

A script without the repository argument should bypass the resolve step and call the script right away.

export async function script(octokit, options) {
  // do something here
}

Technically this should be possible (according to MDN) by calling .length on that function

async function foo(a,b,c,d) {}
console.log(foo.length) // 4

async function foo(a,b) {}
console.log(foo.length) // 2

[gr2m]

Without having any repository context, how can you send the request to archive a repository?

[stefanbuck]

Mhhh yeah well ... looks like I didn't thought it through in its entirety yet. You're right, there needs to be some context at least the org and repo name. Also this doesn't work for wildcards like repo-owner/*or *.

I'll add some user stories and then we can use those to debate whether or not such a change would be useful.

[gr2m]

It feels like a premature optimization at this point, but it's never too early to start a discussion about it

[stefanbuck]

Do you know based on feedback and your own experience if Octoherd is mostly used to batch a rather small set let's say less than 100 repos? In our organization we have over 1500 repositories and I can see Octoherd as a neat tool to do extended analysis and may also make repo settings and even code changes. In such a scenario it could be helpful to spare a few request to make it first faster to run and less likely to run into rate limits (happened to me a few times so far).

[gr2m]

Hm it shouldn't run into rate limits, we do implement proper throttling. That would be a separate issue we should try to address. Worst case scripts would be slow. But e.g. to create nightly reports it should not be a problem? I'm sure there are ways to optimize, I just think that @octoherd is not feature complete yet, and I'd rather wait with optimizations if they complicate implementing the features we want