Remove disable states for the Deploy button

[dotNomad]

We currently have 3 disabled states for the Deploy button in the extension:

1. Resources haven't been selected
2. The selected Configuration is in error
3. There is currently a deploy in progress

---

1. Resources haven't been selected

We do not show the deploy button at all when a Content Record has not been selected.

The deploy button is shown if we have a record selected, but can still be disabled in the two possible states past that:

• the user doesn't have a Credential for the Content Record
• the user doesn't have a Configuration for the Content Record

For both states we show warnings to solve this easily.

We cannot easily remove this since the deploy API in our Go binary requires we pass the name of the both the account (Credential) and the name of the Configuration.

A decent amount of refactoring could remove the need of requiring a Credential in that API call since it can be derived. Credentials are unique to server URLs and we can attempt to find that Credential during the deploy process and fail if it is not found. This is how the extension is determining the "selected Credential" despite the user never making that selection explicit:

publisher/extensions/vscode/webviews/homeView/src/stores/home.ts

Line 93 in 7edfbcb

const serverCredential = computed(() => {

Removal of the Configuration disabled state could be done in much the same way. We can rely on the selected Content Record to point to a Configuration since that is how we determine the selection in the extension:

publisher/extensions/vscode/webviews/homeView/src/stores/home.ts

Line 41 in 7edfbcb

const selectedConfiguration = computed(

The path forward to remove these disabled states would be to refactor the POST /api//deployments/$NAME to not take a account (Credential) or config and derive them on the Go side.

This would free up the extension to always deploy when a selection of a Content Record is made, and allow errors to bubble up with the derivation goes wrong.

---

2. Selected Configuration is in error

We can make the deploy API call to our binary just fine with a Configuration in error since we still have the name of the Configuration.

It will not ever successfully deploy since we validate the TOML file before sending anything up to Connect:

publisher/internal/schema/schema.go

Line 83 in 7830e62

func (v *Validator[T]) ValidateTOMLFile(path util.AbsolutePath) error {

This validation is necessary to get the attributes from a Configuration, but:

• we can allow the pressing of Deploy
• the user can get an informative error from our ValidateTOMLFile function

That looks like the below, when the notification is expanded:

---

3. Deploy in progress

Allowing for deploy while another is in progress is possible, but leads to some odd states.

First it allows users to accidentally double click the button sending up two deploys. We would have to introduce some sort of debouncing or something else to avoid this.

Second we start to get errors where builds failed due to being superseded by a more recent deployment.

There are questions about how we handle this in our current UX when it comes to logging. Currently our Posit Publisher Logs only track the latest deployment. If multiple deployments are going at once you are either:

• only seeing the logs for the most recent
• seeing multiple logs at once (multiple steps in progress) if you are deploying multiple of the same content ID twice

Even if we get into a bad state where publishInProgress remains true (for example a Deployment gets stuck) there are few options forward:

• cancelling the in progress deployment - a feature we added in Feedback: Cancel hung deployment #2057
• or ultimately reloading / re-opening the VS Code window to reset the state

This will require more thought on how to approach removing this disable state.

[dotNomad]

Ultimately I split this out into 3 sub-issues to remove the disable states. The only one that can be removed quickly is #2345 and I will have a branch up for that in a moment.

The others are a bit more difficult. It is possible to get to a point where the only disable state we have is "a Deployment has not been chosen". I don't think we can get away from that one.

[jonkeane]

The others are a bit more difficult. It is possible to get to a point where the only disable state we have is "a Deployment has not been chosen". I don't think we can get away from that one.

Agreed that no deployment has been chosen is a reasonable state to disable the button.

Disabling while deploying also might be reasonable to leave as is. Certainly the state(s) one can get into by pushing that button multiple times are funky. And we do have the cancel action which lets someone get out of the disabled state if they needed to.