exp share refactor - ping on exp:remove, do not fail on error #9248
Conversation
1) Pings Studio on exp remove 2) Does not fail on any error during request.post 3) UI improvement on exp remove
skshetry
added
enhancement
| # TODO: Should we use git_remote to associate with Studio project | ||
| # instead of using `git ls-remote` on fallback? |
There was a problem hiding this comment.
@dberenbaum, a bit of an edge case here.
What project/repository should we associate on dvc exp push origin? The origin remote url, or where the upstream remote was set to (during git push —set-upstream)?
There was a problem hiding this comment.
Since it's an explicit remote, I think it should be the origin remote url. If the user wants to use a different remote, then they shouldn't specify origin, right?
WRT using the upstream remote, there's some very old discussion in #6332 (comment) and #6427. I agree it would be nice to have some way to use the upstream remote, but I think it's not that simple since we aren't pushing a branch and it's not a blocker.
There was a problem hiding this comment.
Sorry, I meant it in terms of a Studio project. We send remote url (aka repo_url) to Studio.
At the moment, we are sending —set-upstream url instead of the remote that is passed as argument on exp-push or exp-remove.
There was a problem hiding this comment.
Thinking about it more, it does not make sense to pass a different repo_url if you have pushed to a separate remote. I am changing it.
There was a problem hiding this comment.
Yep, makes sense, thanks @skshetry!
studio experiments share refactor 1) Pings Studio on exp remove 2) Does not fail on any error during request.post 3) UI improvement on exp remove
request.postCloses #9227.