Allow cross-repository testing to accept repository URLs to cut down on dummy PRs

[AnthonyLatsis]

Currently, if you want to test changes made to one repository against another (for example, build and test swift-corelibs-foundation against a modified Standard Library), you must still open an empty pull request in that other repository as per the instructions. This is counterproductive and pollutes the PR history. A better option is to have swift-ci commands accept both repository and pull request URLs.

[MaxDesiatov]

I'm not sure I understand a motivation here, I've never seen a need to create dummy PRs before. If you're testing against a modified stdlib, you still need to open a PR to contain the modifications. What's the point of specifying a repository URL if unmodified repositories participate in cross-repo testing anyway?

[AnthonyLatsis]

Do you mean to say that a smoke test builds swift-corelibs-foundation and others like swift-collections by default?

[MaxDesiatov]

Foundation - maybe, especially if it's a Linux build that needs SwiftPM. As for Collections, I'm not sure. AFAIU, cross-repo testing does not include in the build process some repository previously ignored in CI configuration. It only switches to a specific branch of a specified repository, with no impact on what will or will not be built/tested.

[AnthonyLatsis]

It only switches to a specific branch of a specified repository, with no impact on what will or will not be built/tested.

Makes sense. I didn’t think this through well enough then. What follows though is that for some repos you currently have to open a dummy PR in that other repo in order to build it against a modified compiler.

[shahmishal]

@AnthonyLatsis Can you provide example of this issue/feature you are requesting?

[MaxDesiatov]

One example is that recently we needed to open a dummy PR on the main Swift repo #63216 to test an associated PR in swift-installer-scripts. Another example is that sourcekit-lsp repository doesn't have Windows CI, due to which it frequently regresses, and the only way to test it is also by creating a dummy PRs on the main apple/swift repository and requesting a Windows toolchain to be built on those.

[AnthonyLatsis]

Here is some context. A couple months ago I authored a pull request where I obsoleted some swift-corelibs-foundation SPI declared in the Standard Library, and so I had to open a dummy PR in that repo in order to cross-test with the swift PR (I am actually not entirely sure it even built swift-corelibs-foundation, because I triggered the tests from the swift side).
In such cases, I thought it would be nice if you could tell the bot to checkout and build the latest revision of another repository by specifying the repository URL, like so:

https://github.com/apple/swift-corelibs-foundation
@swift-ci please test

[shahmishal]

swift-corelibs-foundation is built part of Linux an Window platform testing on apple/swift repository, and the update-checkout script will check out the top of tree for targeted branch scheme.

[AnthonyLatsis]

swift-corelibs-foundation is built part of Linux an Window platform testing on apple/swift repository

I see, so the dummy PR was redundant in my specific case. At the risk of being contrived, the point is that AFAIK other subprojects such as swift-collections are checked out but not built at all as part of apple/swift PR testing, regardless of whether you test with an associated PR.