Feature Request / Bugs

[mvastola]

First off, I'm really happy I just found this browser extension and I thank you very much for it.

One thing that I'm really looking for in apps, but I've yet to find (at least for Linux), is the ability to filter CI tests to only builds you, yourself initiated, be it manually, or by a push/commit.

I'm not sure if/how easily accessible this data is for all providers, but at the very least for BuildKite, it's included in the build details. If you work somewhere where many different people are constantly testing different branches in the same repo, the tests of your work are easily lost.

---

Beyond that, here are some UI problems/like-to-haves I noticed just in configuring things. I thought I'd mention them in the hopes it helps you focus on things that could be improved (or that people should make PRs for, I may make some too).

Please just don't take this to be hypercritical. This is an incredibly useful tool. I just find bugs for a living, so I spot a lot. :stuck_out_tongue:

Configuration UX/Functionality

• You shouldn't have to re-"Show" the pipelines for a CI tool to select (or, especially) de-select them.
• Also, when selecting pipelines to monitor, the checkbox on the pipeline name is a no-op. (i.e. you can't use it to select all or none.. it does nothing that I can see.)
• If I missed this option I apologize, but but there should be an option to tweak the number of past builds shown for each repo.
• I don't use all these services, but at lease for Travis:
  • It should be possible to monitor public repos by giving their full URL. Right now if I type https://api.travis-ci.com/repos/attr-encrypted/attr_encrypted, it theoretically should work, but Travis adds another /repo to the end of the URL, causing all requests to fail.
  • This is potentially related, it should be possible to give your Travis "Asset Token" rather your "API Token" (which grants read-only rather than read-write permissions). I think the you might have chosen the latter because it allows listing a persons project/repos, but if a user can specify those themselves, there is no need.

Purely Cosmetic

• The dark mode setting should apply to the configuration pages as well
• There should be a bit more user feedback when re-ordering pipelines within a CI service. (The handle to drag them is hard to see, and it's hard to see if the move will be successful if you release the cursor at the current position).
• When you turn the main 'Notifications' toggle off the sub-option names become bold, and when you turn it on they lose their boldness. You obviously intended the reverse. (Also, it'd probably be more intuitive to disable the toggles/grey them out as they still can be flipped.)
• In the 'View' config, it's impossible to tell what "Collapse Groups" does, at least for my list of configured projects.
• In Travis (and possibly more)
  • It should be a little clearer visually that -- without a private repo -- the travis-ci.com/org prefix is going to be added to the URL when you paste. (Perhaps with a drop down with an 'other'?)
  • If using travis-ci.com, .org or an on-premises configuration, the link URL shouldn't be needed, as the URL to the repo should be returned with the list of builds. (The two URL prompts really confused me at first.)

[AdamNowotny]

Thank you for taking the time to describe the improvements! The development hasn't been very active for a while but knowing that others still find it useful gives me the motivation to get back into it. I can take a look at the general issues but Travis CI specific issues would be a good candidate for PRs because I just haven't used this CI for a while. I'll find some time to do some analysis of the work and post an update.

[mvastola]

Well in that case I'm really glad that was helpful. :-) Travis is the one I use least, but I'll see what I can do. None of these things were really big.

And yeah, it's honestly surprising how there are like no other tools that do this (at least on Linux). This one has a ton of potential. :-)