ui: Incorporate pushed artifacts into build display

[jgwhite]

Why the change?

Primarily to address #1287, though adding the foundations for artifact-awareness will likely be useful for other features.

Could we load pushed artifacts in a more efficient manner?

“Yes, but not yet…”

We’re currently exploring the idea of adding dedicated aggregate API methods for aspects of the UI such as this. Watch this space. Until we have such a thing, this load-and-cross-reference approach is the only one available.

What’s the plan?

• Add changelog entry
• Add pushed artifacts to Mirage
• Refactor app route
• Load pushed artifacts in app route
• Incorporate push status into <AppCard::Build>
• Incorporate push status into <AppItem::Build>
• Fix capitalization of initialisms (i.e. AWS)
• Add aws-ecr to icon-for-component
• Write some test steps
• Improve design

What does it look like?

Obligatory video:

pushed-artifacts-demo-1080p.mov

How do I test it?

Using Mirage

1. Check out the branch:

   git checkout ui/pushed-artifacts

2. Boot the dev server

   cd ui && ember serve

3. Visit the app
4. Verify you see information about pushed artifacts in addition to builds
5. Verify that the UI makes sense

For realsies

1. Check out the branch:

   git checkout ui/pushed-artifacts

2. Build the ember app

   (cd ui && make)

3. Bundle the static assets

   make static-assets

4. Build the dev server

   make docker/server

5. Build the CLI

   make bin

6. Install waypoint on your platform of choice, i.e.

   ./waypoint install -platform=kubernetes -accept-tos -k8s-server-image=waypoint:dev

7. Open the UI

   ./waypoint ui -authenticate
   

8. Try out an example app of your choice (i.e. kubernetes/nodejs)
9. Verify that you see information about pushed artifacts in the UI
10. Trying triggering a failed push (see ui: if a registry push fails, can't see that anywhere #1287 for an example)
11. Verify you see the overall state of the build is failed

[jgwhite]

@almonk there’s a bit of a design challenge with this change.

In this screenshot, we display both operations (build and push) in the build card and list items, and display the status of whichever is later (should be the push) as the overall status. The result is potentially a lot of icon duplication.

My gut says this is not terrible but rather inelegant and I suspect the layout probably falls down in some edge cases. Would love your take when you get a change to look at it.

[jgwhite]

Idea from @almonk:

[jgwhite]

Reflecting on this, I think @almonk’s design suggestion make it realistic for this to land in 0.5.0. Have updated milestones and project tracking accordingly.

[jgwhite]

Just noticed that we could do with applying the same logic to the build detail page. Going to add that in here.

[jgwhite]

Just noticed that we could do with applying the same logic to the build detail page. Going to add that in here.

Addressed in f36048c

[gregone]

Looking great!

[sabrinako]

Looks good! Saw the demo video