Enhance ci-status #449

Open
krlmlr opened this Issue Dec 11, 2013 · 9 comments

4 participants

@krlmlr
  • Get rid of -v switch, should be default
  • Supply -b switch for opening in browser (like hub browse)
  • Perhaps supply -q switch

I could give it a try, but I wanted to discuss that first.

@mislav
GitHub member
  1. I'm not entirely sold on the idea that -v should be the default. On the other hand, getting the URL right away is useful for failed builds because you probably want to inspect the failures. I'll think about it.
  2. Not a bad idea
  3. I don't think -q is necessary, when you can pipe stdout to /dev/null
@krlmlr
  1. hub pull-request also always prints the URL.
  2. -
  3. OK.
@pengwynn
GitHub member

I'd love to see a -b switch. As someone that's often calling hub from other custom scripts, I like the default output. -v isn't too much to add if I really want to see more.

@krlmlr

I'm still interested, but I don't think I find the time to implement this any time soon.

@mislav mislav added the feature label Dec 23, 2014
@mislav
GitHub member

hub ci-status in master branch supports multiple build statuses and displays the breakdown with -v. #999

$ hub ci-status -v
✔︎       continuous-integration/travis-ci/push   https://travis-ci.org/github/hub/builds/103531630
✔︎       GitHub CLA                              https://cla.github.com/github/hub/accept/mislav
✔︎       continuous-integration/travis-ci/pr     https://travis-ci.org/github/hub/builds/103531958

The non-verbose output is still the default for backwards compatibility. With multiple build statuses, which one should be opened if we add -b switch?

@krlmlr

Can -b open all of them? There might also be an arg -B # that specifies which ones to open, or a --browse-failed that opens the URLs for all failed statuses.

@matthauck

What about adding the ability to create statuses with hub? Would be neat to be able to use hub as the backend for powering things like build status, code review, etc. (Not sure if that fits in the scope of this issue, was gonna create a new issue, but seemed to fit here)

@mislav
GitHub member

@matthauck I feel that this functionality would be out of scope right now since the tools which report status updates to GitHub API should rather be interfacing with it directly rather than through hub.

@matthauck

Sure. Fair enough. =)

@mislav mislav referenced this issue Aug 17, 2016
Open

List of features for the next big release #1232

7 of 37 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment