posit-dev / publisher

MIT License
6 stars 1 forks source link

Improve Secrets view by reflecting server Environment Variable states #2414

Closed dotNomad closed 3 weeks ago

dotNomad commented 3 weeks ago

This PR introduces a new feature for the Secrets view showing more detail based on the state of the content on Connect using the Get environment variables API endpoint.

image

Now the Secret will be de-emphasized if it already has a value is on the server, and emphasized when an action needs to be taken or is currently being taken (for example setting a value) by the user.

Additional the codicons are improved showing:

The tooltips are also improved for the 4 different states the Secrets can have.

Intent

Resolves #2365

Type of Change

Approach

The approach is similar to our other features, this one being a bit more unique since it potentially calls the Connect API.

When the Configuration changes or the Deployment changes we make a request to the binaries API at GET api/deployments/$NAME/environment which handles whether it should error or if it has all of the details to call Connect.

If Connect is called we either silently error if the API errors (for example from a missing piece of Content from deletion or auth errors) or we send the web view the array of Environment Variable names.

From there the names are put into the webview Pinia store to compare with the secrets the user has locally set or unset.

One thing to note about the approach is that the updateServerEnvironment method in the homeView fails silently. The idea here is that the environment updating flow may not be the best place to surface more general errors like the content missing or auth errors. Instead the errors from our API or the Connect API are captured and the web view is told there are no Environment Variables.

Most cases where our binaries API can fail this doesn't impact anything. Those cases are:

Once a failure happens on Connect that is more note-able, but it felt out of the scope of this ticket to surface those errors.

Why request the server environment on Configuration changes?

The content record could have a new secret added.

Why request the server environment on Content Record changes?

The content record changes when a deployment is made, so we update the server environment afterwords to ensure that what is displayed is correct.

Directions for Reviewers