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.
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:
a warning when the Configuration has a Secret declared that is not on the server yet
showing a cloud upload icon when a value is ready to be sent up
showing a check mark when the server already the Environment Variable set
The tooltips are also improved for the 4 different states the Secrets can have.
Intent
Resolves #2365
Type of Change
[ ] Bug Fix
[x] New Feature
[ ] Breaking Change
[ ] Documentation
[ ] Refactor
[ ] Tooling
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:
the content record file doesn't exist
the content record file is in error
the deployment has not been deployed
the credential is missing
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.
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.
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 thehomeView
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