feat: support copy repository to custom directory

[CarlJi]

Prow and its library are quite friendly to CI infrastructure, and we have been using them extensively.

This PR aims to enhance the customization capability of its code workspace, similar to Jenkins's checkout to sub-directory feature. This way, within the same workspace, there will be opportunities to accommodate more repositories to address complex scenarios.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: CarlJi Once this PR has been reviewed and has the lgtm label, please assign droslean for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[pkg/OWNERS](https://github.com/kubernetes-sigs/prow/blob/main/pkg/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[k8s-ci-robot]

Hi @CarlJi. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.

[netlify[bot]]

✅ Deploy Preview for k8s-prow ready!

Name	Link
🔨 Latest commit	bebdfa40721045139e3cb527590b7757b74d81dc
🔍 Latest deploy log	https://app.netlify.com/sites/k8s-prow/deploys/66e4fa14533f7b00087ad055
😎 Deploy Preview	https://deploy-preview-214--k8s-prow.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[petr-muller]

/test all /hold

This PR aims to enhance the customization capability of its code workspace, similar to Jenkins's checkout to sub-directory feature. This way, within the same workspace, there will be opportunities to accommodate more repositories to address complex scenarios.

👋 can you describe what kind of scenarios are you interested in? The client library is able to checkout multiple repositories (via multiple ClientForWithRepoOpts calls), just not under the same temporary directory (but the location under the temporary directory is supposed to be an irrelevant internal detail. I'm not sure I see the benefits of having them in the same directory.

[CarlJi]

Hi @petr-muller, thanks for your feedback.

In this project, we utilize prow git library to prepare a clean code workspace for PR in order to do all kinds of linters check.

The need for this capability arises from our utilization of replace in go.mod to reference certain private repositories, for example:

replace github.com/qiniu/log.v1 => ../kodo/src/github.com/qiniu/log.v1
replace github.com/qiniu/errors => ../kodo/src/github.com/qiniu/errors

In this context, kodo represents another private repository. Consequently, we need organize these distinct repositories and position them at the same directory level for compiling.

Another, our project has config like this. so with this functionality, I can address this scenario like the following:

- | 
  cd .. && git clone xxx && cd -
  golangci-lint xxx

It will be very straightforward.

but the location under the temporary directory is supposed to be an irrelevant internal detail

Seems that this is the actual code directory, the real workspace. i am thinking It would be more elegant with such capability.

[petr-muller]

/test all /hold cancel

[krzyzacy]

/ok-to-test

[CarlJi]

After deeper reflection and practice, I am considering the possibility of directly supporting "Copy to custom directory," which might be more elegant. This approach should be able to accommodate a wider range of use cases.

Please help review @petr-muller @krzyzacy

[krzyzacy]

I'm still catching up on the latest Prow changes, previously we leverage path_alias for repo dest locations Prow jobs, but seems you are only referencing the Prow git client instead of the actual Prow jobs?

[CarlJi]

Yes, The background context is that I am building a unified linters runner to standardize engineering practices across multiple orgs and numerous repositories. Compared to configuring Prow jobs for each repository, a centralized, low-configuration, and observable service would be more convenient for me.

Of course, I still choose to use some of Prow's foundational packages, as they are indeed very useful.

[krzyzacy]

Where do we set this option? From your own controllers? I would suggest open an issue with the descriptions or your use case, and then associate your PR to the issue :-)

Could you also add a unit test to assert the behavior?