(feat) add "src repos {add|update|delete}-metadata -repo-name" flag support

[erzhtor]

Part of https://github.com/sourcegraph/pr-faqs/issues/96.

This PR adds src repos {add|update|delete}-metadata -repo-name flag support

NOTE: When using repo-name flag, it makes an extra GQL query to get a repo ID. This is made for back compat purposes instead of introducing breaking change and updating underlying add/update/delete repo metadata GQL query.

Test plan

• Add/update/delete using repo flag as previously
  • go run ./cmd/src repos add-metadata -repo=$repoID -key=test
  • go run ./cmd/src repos update-metadata -repo=$repoID -key=test -value=value
  • go run ./cmd/src repos delete-metadata -repo=$repoID -key=test
• Add/update/delete using repo-name flag as previously
  • go run ./cmd/src repos add-metadata -repo-name=$repoName -key=test
  • go run ./cmd/src repos update-metadata -repo-name=$repoName -key=test -value=value
  • go run ./cmd/src repos delete-metadata -repo-name=$repoName -key=test

[camdencheek]

nice!

[eseliger]

The other commands seem to follow a different naming scheme, usually src ENTITY ACTION params so for example src teams create and such, should we align here?

[camdencheek]

usually src ENTITY ACTION params

Is that not what this PR does? I'm reading a command like src repos add-metadata with ENTITY being "repos" and the ACTION being "add metadata"

[eseliger]

Kinda, I thought that repo metadata would be the entity, but could be convinced otherwise 😀 src repo metadata add and so forth.

[erzhtor]

Kinda, I thought that repo metadata would be the entity, but could be convinced otherwise 😀 src repo metadata add and so forth.

Thanks for the feedback, @eseliger. TBH I haven't thought repo-metadata as an entity, but now that you've mentioned it, I think that does seem to make sense. On the other hand, though, repo metadata is part of a repo and can't exist independently, so both ways of thinking repos as an entity or repo-metadata as an entity could work.

For the scope of this PR, I would like to keep this as is, as changing will require more effort and refactoring to make it work both the new way and the old way for backward compat purposes.

[eseliger]

That's okay 👍