Integrate remaining share experiment command with the extension (exp push)

[mattseddon]

1/3 main <- this <- #3792 <- #3793

Relates to #3574.

This PR integrates exp push with the extension. As per this I've renamed the action from "Share" to "Push".

Demos

Share with clickable link

Screen.Recording.2023-05-01.at.10.31.31.am.mov

Error

Screen.Recording.2023-05-01.at.10.30.31.am.mov

[mattseddon]

EXPERIMENT_VIEW_PUSH was already set above 😕

[mattseddon]

[F] This is non-blocking. User can push as many experiments as they like without setting the token.

[skshetry]

@mattseddon, what do you think about making "View in Studio" to be a button like in the case of error?

[mattseddon]

@mattseddon, what do you think about making "View in Studio" to be a button like in the case of error?

In order to use a button for that link I'd have to switch APIs and send another toast message after the progress notification completes/closes. In the case of an error, the progress notification closes unexpectedly and we fallback to some existing behaviour.

[julieg18]

Great work!

[dberenbaum]

@mattseddon, what do you think about making "View in Studio" to be a button like in the case of error?

In order to use a button for that link I'd have to switch APIs and send another toast message after the progress notification completes/closes. In the case of an error, the progress notification closes unexpectedly and we fallback to some existing behaviour.

Looks great @mattseddon! Agree with @skshetry that error handling is my one question here. When the cache fails, not showing what has been successful (pushing to GitHub, pinging Studio) feels confusing. Is there anything we can do to at least show the info about what parts of the push were successful like we do in CLI?

[shcheklein]

LGTM!

• One question - do we plan to have a separate "Share" action or do we expect users to understand that Push does this - essentially solves their high level use case - to see an experiment from Studio? cc @dberenbaum (I'm bit worried that it's now too low level)

• An experiment can be auto-pushed, right? And live-shared - does it affect this action? Probably all of this comes down to us being able to show a link / status of an experiment.

Not blockers, some followup questions to discuss.

[mattseddon]

Looks great @mattseddon! Agree with @skshetry that error handling is my one question here. When the cache fails, not showing what has been successful (pushing to GitHub, pinging Studio) feels confusing. Is there anything we can do to at least show the info about what parts of the push were successful like we do in CLI?

Is this important? In order to rectify the error the user is still going to have to fix the problem and push again regardless of which parts are successful.

One question - do we plan to have a separate "Share" action or do we expect users to understand that Push does this - essentially solves their high level use case - to see an experiment from Studio? cc @dberenbaum (I'm bit worried that it's now too low level)

No plan right now, change is related to this comment:

@dmpetrov Made a point about distinguishing between all the different options we have in the workflow today. For the dvc exp push action, what do you think about explicitly using "push" instead of "share" for the action name? I think it is more explicit and specific, giving more clarity that it's related to git push/dvc push and separate from "live" sharing.

[codeclimate]

Code Climate has analyzed commit 82ea04a and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 86.6% (85% is the threshold).

This pull request will bring the total coverage in the repository to 94.6% (-0.1% change).

View more on Code Climate.

[skshetry]

@dberenbaum, I was asking for an actionable button.

Is this important? In order to rectify the error the user is still going to have to fix the problem and push again regardless of which parts are successful.

@mattseddon, see iterative/dvc#9342. The reasoning was that:

1. most of the metrics/plots/params are going to be git-tracked
2. and, even if we did not notify Studio, Studio could still parse them anyway if it got updates through other means.

This will be in the next release though, I just merged the PR.

[dberenbaum]

• One question - do we plan to have a separate "Share" action or do we expect users to understand that Push does this - essentially solves their high level use case - to see an experiment from Studio? cc @dberenbaum (I'm bit worried that it's now too low level)

What about "Push to share"?

I thought "push" was more explicit and "share" alone may be an abstraction that doesn't tell users what's happening (and could be confused with "live sharing"), but not a blocker if you feel strongly about calling the action "share."

• An experiment can be auto-pushed, right? And live-shared - does it affect this action? Probably all of this comes down to us being able to show a link / status of an experiment.

Auto pushing is only currently possible in very narrow scenarios. Neither auto pushing nor live sharing should affect the action. Is your question about seeing what has been shared?

[shcheklein]

Is your question about seeing what has been shared?

Yes. Connection between Studio and VS Code is still not clear to my mind.

that doesn't tell users what's happening

why do you feel they need to know what is happening? Tbh I thought we should focus more on making it clear what is that they are getting as a result (vs an implementation details).