Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sharing deployment logs with the user for pending/error #27

Open
paulirish opened this issue Jun 3, 2017 · 2 comments
Open

Sharing deployment logs with the user for pending/error #27

paulirish opened this issue Jun 3, 2017 · 2 comments

Comments

@paulirish
Copy link
Contributor

paulirish commented Jun 3, 2017

After working on #26 I identified some followup work I think would improve the experience. (TBH it seems equally valuable both in commit status API and deployments API)

User story

If there's a failure in the deployment, you'd want to see the logs from now.sh.
The Github deployment API has thought of this and its "log_url" property can be supplied the http://****.now.sh/_logs/ URL. The pending status will then be user visible where they can click through and monitor the build.

This also is valuable if there's a failure in the now build. (I experienced one of these in one of my projects---the root cause: .gitignore & compiled files)

Implementation

Essentially, the moment we have a non-aliased now URL, we want to update the pending status to include this _logs url.
The challenge is that the stage method in core doesn't allow for exiting twice: First, with url so we can setStatus with it. Then, once the process's close has fired and alias'ing completes.

I gave it a shot but nothing really felt right.. so @zpnk you're probably the best to take a look at this. :)

@zpnk
Copy link
Owner

zpnk commented Jun 6, 2017

I like this idea a lot, 👍 from me.

In terms of implementation, I think we're going to need to refactor the stage method a bit to allow for this. Right now, it's probably doing a bit too much since it's running the $ now deploy process and the $ now alias process.

I'd be in favor of refactoring the aliasing logic out into it's own method and having stage() (maybe rename to deploy()?) resolve the intermediate now url.

Ideally, we'd be able to write something close to this:

// pseudo code~

await sync(cloneUrl, localDirectory, {ref, checkout: sha});
const nowUrl = await deploy(localDirectory); // stage() -> deploy()
await setStatus('pending', 'Deploying...', `${nowUrl}/_logs`);
await alias(nowUrl, alias) // whoops, naming collision
await setStatus('success', alias, alias);

@paulirish
Copy link
Contributor Author

@zpnk yeah very nice. though I'd add one wrinkle..

There's often quite a bit of time between when a domain is allocated for the deployment (and _logs become available) and when the deployment finishes.

So in this case, it'd be ideal to setStatus immediately after the domain is allocated so the logs can be exposed to the user. Just looking at when data is emitted to stdout, it appears when get the url is right when the domain allocation happens. Phew!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants