`cml-pr` failure handling

[casperdcl]

• p1/p0?: cml pr should complain (exit non-zero) if a PR already exists, and also have a --force flag to suppress the warning and force-push an update to the PR. This is a likely scenario in case of e.g.
  • restarted workflow, or
  • long-running job where the user wants to open a draft PR and update it multiple times
• p2: if branch "${BASE}-cml-pr-${SHA}" already exists on the remote but there is no associated PR, then cmp pr fails. Instead, it should open a PR.

originally from https://github.com/iterative/cml.dev/pull/114#discussion_r720283843

[DavidGOrtega]

Could you please reproduce such scenario? In which case the user is going to create manually that branch?

[0x2b3bfa0]

Moved from #788

The cml pr command has the debatable behavior of remaining in the ancillary pull request branch (e.g. main-cml-pr-ff404ff) instead of switching back to the previous branch with git checkout - upon completion.

If this behavior were consistent, it would be acceptable. Unfortunately, cml pr does not fail when the pull request already exists (https://github.com/iterative/cml/issues/758) and this introduces an edge case where the pull request is reported as created but no branch is switched.

[0x2b3bfa0]

Not sure if cml pr should fail or not, but, if not, it should probably be idempotent–ish.

[casperdcl]

I think either:

• fail nosily on conflicts, or
• avoid conflicts à la SO/70205896#3896283

[dacbd]

partial solved or at least workarounds are provided with https://github.com/iterative/cml/pull/1063

Perhaps the only additional action point is to log some warning if we skip creating the PR because the generated branch already exists.

[casperdcl]

Yes I think this is a needed UX (error messaging) improvement.

[casperdcl]

re-opening as it's affecting @ykasimov and probably others...