[Maestro++/darc] Darc cannot set merge policies for repositories unless the repository already has merge policies

[riarenas]

• [ ] This issue is blocking
• [X] This issue is causing unreasonable pain This causes problems when trying to set policies for new / renamed repositories

Darc makes this call before allowing the creation of merge policies for a repository: https://github.com/dotnet/arcade-services/blob/30a11c39465739dec470b8b871753925de98d5dd/src/Microsoft.DotNet.Darc/src/Darc/Operations/SetRepositoryMergePoliciesOperation.cs#L121

This call checks that the repository already has either a merge policy, or there has been a subscription that has posted a dependency update PR, so it fails when trying to set the policies for a new repo (or when it has been renamed)

We should instead do one of these two things:

• Not check anything and allow the merge policy to be created regardless
• Just check the repositories table to see if the repo has an installation ID. I believe we currently don't expose an API that looks at the repositories table.

[alexperovich]

I think it would be best for the maestro api endpoint that sets the merge policy to just fail with a useful error when this happens. Darc can just not check anything, and let the server fail. The client will marshal the error message back from the server.

[riarenas]

Yeah, we could change the error message to say "create a non-batched subscription and trigger it first" instead of saying there's no maestro installation, since we're not really checking the maestro installation.

[alexperovich]

Well, the server could actually check the installation, because the "create a merge policy" operation doesn't need an existing entry in the RepositoryBranches table.

[riarenas]

Yep, that's my preferred solution as well (option 2)

[alexperovich]

My interpretation of option 2 was "create new api in maestro to expose the repositories table, then have darc call it". I would rather "have darc just call the create merge policy api without any checks, and have that call fail if the repository doesn't have an installation"

[riarenas]

Oh, yeah, that's good. let's do that.

[michellemcdaniel]

@alexperovich @riarenas any idea where this should be triaged? Maybe the dependency flow epic? FR since it's causing pain?

[riarenas]

The error only happens with renamed and new repos that exclusively want to use batched subscriptions, so I don't think it's FR. Dependency flow epic seems correct. I can move it when I'm back on a pc.

[premun]

We can now figure out the installation from GitHub API (we do that during subscription creation). We could call the same method when creating merge policies and adding default channels.