Listen for and show publish failure events in progress view

[dotNomad]

This PR makes each step in the publish process subscribe to its correlated /failure server side event. It uses the same msg.data.message extraction and places that inside of the logs passed to PublishStep.vue which styles error logs and the surrounding expandable section.

Preview

Intent

Resolves #302

Type of Change

• Bug Fix
• New Feature
• Breaking Change

Approach

My approach here was to make the generic component PublishStep.vue style itself differently if it received a log message that was an error. If it contains an error message it hasError = true which changes the icon, color, and stylizes the error to be semi-bold (medium weight) and red as well.

Some TypeScript changes (types and type predicate functions) were needed to distinguish from a generic string log message and an AdvancedLog message which kept the usage of PublishStep.vue as simple as possible.

A lot of the changes in the publish step components is the same other than the event they specifically subscribe to.

Directions for Reviewers

Create an error when publishing to see the error get handled. The easiest example that I used was pointing to a non-existent destination like a stopped localhost:3939.

Keep in mind we cannot cancel a publish, and an error message doesn't currently set publishInProgress = false to allow the usage of the back button. Of course we can change that in another PR or here based on feedback.

[sagerb]

Just a couple of nits.

Nice and simple overall.

[sagerb]

The specification of the actual color should come from the color store as a computed value.

[dotNomad]

Oh I assumed that we would use the color store if the color wasn't consistently the same. I will switch this over to using the store.

[dotNomad]

Addressed in 66f712d

I kept it pretty generic colorStore.activePallete.textError so the error text wasn't specific to the part of the UI we were in. Let me know if you had something else in mind.

[sagerb]

Perhaps we should move Log type definition outside of PublishStep, and have it located with our other API types?

[dotNomad]

I'm personally comfortable having this type in the PublishStep component for it to specify for itself what it takes a log for its logs prop.

If this gets re-used in multiple components then I think it should be extracted and shared.

However to touch on your question if it should be located with our other API types - I don't think any type that isn't related to the API responses, API requests, or how we interact with them should be located in the api module.

[sagerb]

I agree it should, but in this case, aren't you simply replicating exactly what was being sent in on the event message? So I would think it would own the type unless it was changed by the prop? This is where my observation was coming from...

[dotNomad]

After a discussion we agreed that I am replicating the event msg structure and we can pass that directly to PublishStep without much issue.

[dotNomad]

Addressed in 79fdf6e

[sagerb]

Thanks for the updates! LGTM!

[kgartland-rstudio]

Failure scenarios tested:

Create Bundle:
✅ Deploy a non-existant file

Create Deployment:
✅ Deploy to an invalid server

Restore Python Environment:
✅ Deploy while omitting a requirements.txt file
✅ Deploy to a server with mismatching python version

Run Content:
❌ Deploy with a bad import statement

I attempted to give the app a bad import statement and expected this step to fail since it fails in Connect.

How is the Run Content step validating that we're able to run content?

Recently in rsconnect-python @mmarchetti included a Verifying deployed content step, should that same logic be applied here? LMK if this should be a separate issue.

[mmarchetti]

LMK if this should be a separate issue

Verifying app deployments are live should be a separate issue. For now, you could test having a bad import in a jupyter notebook, which will fail rendering and therefore the deployment.