Habitat: [builder ui] Make it more apparent when Origin keys are not present

[reset]

As a user who is connecting a plan
I would like to be alerted that I don't have the appropriate keys before I trigger a build
so that I don't have to troubleshoot why it failed only to discover it was easily preventable.

We already auto generate keys when a build is kicked off if they aren't present, but we should alert people of this situation first as we'd be potentially invalidating existing keys.

When you create a new origin, there is a checkbox (enabled by default) to generate keys right then. This is beneficial for sever reasons, namely 1) it raises awareness that origins have/need keys 2) it clears the way for you to connect a plan and successfully build a package and 3) it provide you an option to not generate keys in the event you created this origin locally via the CLI tool first (and already have keys locally; and now you won't have to download new keys and replace local keys).

Kicking off a build without the proper keys is a bad experience that is preventable. Let's alert people up front, when they attempt to connect a plan, if we detect the origin keys are not present.

To-dos

• [x] UX: provide a mockup/prototype showing the alert and providing appropriate explanation/hints
• [x] DEV: add link and disable 'connect a plan file' button according to mockup below. The Add origin keys link simply take you to the Keys tab
• [x] DEV: Change ORIGIN KEYS checkbox to note on Create Origin screen.

Mockups

Mockup of Origin without keys
Mockup of Origin Keys note on Create Origin screen

[ryankeairns]

On further thinking I'm not convinced removing the checkbox is the way to approach this problem. Is it accurate that if you auto-generate a new key pair, then the user would have to download and update/replace their local keys? If so, then it seems you may not want to generate keys in some circumstances and the checkbox would then be handy.

What I like about the checkbox is that it makes it evident that Keys are even a thing and it indicates what they're for... and, by unchecking that box, you're saying "I got this" and would understand if/when your build were to fail later due to lack of keys being present.

Regardless, I think another way to approach this is to stop you at the 'connect a plan step' and say "hey, we don't have the necessary keys to perform this build"

[ryankeairns]

clicked wrong button

[reset]

@ryankeairns yeah I think the approach of "we're missing the keys!" is also a solid solution. It might even be better since as you point out, you might not want to regenerate your keys. You mind editing the issue if that's the route you think we should go?

[ryankeairns]

How do people feel about disabling the 'Connect a plan file' button with a link to add (or generate) keys? (screenshot below)

Currently, you cannot request a new build without first connecting a plan, which would presumably reduce the number of build failures where origin keys are not in the depot. In other words, in order to kick off a build, you must connect a plan. In order to connect a plan, you must have keys present.

The one loophole here is that if you connected a plan on an existing repo post 10/9 Builder launch (and up to this change), then you could still hit this failure. That said, you can still discover the issue in the build output or, iirc, we just generate the keys anyhow.

cc/: @cnunciato @chefsalim

[robbkidd]

Just ran into this one with a connected plan and a build started without a private key present in the origin. So, something to prevent me from doing that is 👍 .

[mwrock]

We check for keys when you request a build and automatically generate a key pair if one is missing. So "in theory" this should not be an issue. If your origin is missing either a private key or a matching public key, we should be creating those on the fly when you hit the green build button.

That said, I do think it is better to be explicit and have the user themself initiate the key generation rather than us doing it magically in the background.

[robbkidd]

I have a build job that was triggered by a GitHub webhook when the origin had a public key, but did not have a private key. That build job failed. It did not create anything on the fly. Is that a difference between webhook'd builds and green button pushes?

[mwrock]

OH WEBHOOK. That totally slipped by me. Thanks. That is different and we do not generate the keys in that scenario.

[robbkidd]

Here's the information I had on that build job:

• origin chef_community_engineering had a public key, but not a private key
• webhook fired
• build failed (I assume a timeout)

I deduced that it was a private-key-missing problem. I added the key, pushed the green button, and the build succeeded.

[reset]

@robbkidd the webhook bit is a really good find. @ryankeairns if we want to continue to go the route where we don't auto generate keys, we'll need to highlight specifically why your build failed when the user goes to the build jobs tab and instruct them to generate keys and re-run their build.

I think after discovering this case I'm pushed a bit closer to the side of we should just auto-gen keys. I know we were wanting to preserve the CLI experience where in you run setup and then go to the website to create your origin and then upload your keys, but I think we could just as easily improve upon that experience by just allowing you to create an origin by CLI and upload keys to it in one go. I think power users would prefer this approach anyway. All in the UI or all in the CLI 😄

What do you think?

[ryankeairns]

@reset , et. al., perhaps we do both?

1. In the UI, we disable 'connect a plan file' until you add keys. Hopefully, this is a small number of use cases going forward. We could also, instead of removing it, change the 'generate keys' from a checkbox to a paragraph/note informing the user that keys WILL be generated.

2. For the webhook scenario, if your build fails (regardless of the trigger, really), we pipe the failure reason back into the UI on the build output page. So, not only display it in the streaming build output, but above the output box as a separate HTML element/banner/message.

There's a third item here too, which you mentioned, and that is - if you create an origin in the CLI, we push it (and its keys) up to the depot. Creating origins in both places is currently a bit of a hassle and point of confusion. The additional twist to uploading it from the CLI is that we would need internet access and the ability to verify that it does not already exist and, if it does, stop (or give the option to stop) creation of that origin.

For starters, I think we should tackle both parts of 1) and also figure out 2) broadly (i.e. consider bubbling up the build failure reason at all times, not just for missing origin keys).

Longer term, or separately, we tackle the current dual origin creation points (CLI and UI). That one feels a bit thorny and likely deserves a deeper discussion... I suspect the solution there will be a bit more challenging.

Thoughts?

[ryankeairns]

@cnunciato this issue will be about item 1. in my previous comment.

I'll split out item 2. into a new issue and link it here.
Item 1. is the current priority.

[ryankeairns]

Split item 2. out into #3735