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

add easy and performant way to have project status in shell prompt #20

Closed
rkh opened this issue Jan 20, 2013 · 7 comments
Closed

add easy and performant way to have project status in shell prompt #20

rkh opened this issue Jan 20, 2013 · 7 comments

Comments

@rkh
Copy link
Contributor

rkh commented Jan 20, 2013

No description provided.

@sarahhodne
Copy link
Contributor

We could cache by current commit SHA here? This would break down if we restart a job, thought.

@rkh
Copy link
Contributor Author

rkh commented Jan 20, 2013

Right. We could also have a background process write the state somewhere.

@rkh
Copy link
Contributor Author

rkh commented Jan 20, 2013

Do we want it to display the latest build or the status of the currently checked out commit? Because for the first one (which would be easier and reliable to implement) the caching wouldn't work that well...

@sarahhodne
Copy link
Contributor

Right. I've tried looking into adding caching to Travis Lite as well, and it's not easy, seeing as things change a lot.

Could we latch onto the pusher feed in a background process?

@rkh
Copy link
Contributor Author

rkh commented Jan 20, 2013

That's what I was thinking. I was playing with the idea of adding pusher support to the library anyways (see #15), but I'm not sure how much hassle that would be.

@rkh
Copy link
Contributor Author

rkh commented Jan 20, 2013

General HTTP caching can be done via ETags, btw, but you'd still need one HEAD request for checking if the cache is fresh. Given that on some setups it might not even be acceptable to fire off a new Ruby process for displaying something in the prompt, I don't think that's an option, though.

@rkh
Copy link
Contributor Author

rkh commented Jul 23, 2013

I think this is unrealistic with our current performance.

@rkh rkh closed this as completed Jul 23, 2013
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