TKL Bugs - Cli turnkey bugtracker

[OnGle]

Something nice that could potentially aid development and speedup certain jobs would be a small program which checks for issues against an appliance with filtering options for labels.

For example tklbugs lamp -l bug would return all issues tagged with bug and lamp.

Also perhaps a smart option which detects if you are in a turnkey related repo so you could just run tklbugs -l bug and if you were in products/lamp it would automatically return all issues tagged with bug and lamp.

Use Cases:

• you are working with a high volume of apps and keep forgetting which apps have which bugs
• you're working on an appliance and want to quickly check if there are any open bugs to fix without having
  to open a browser
• you are building a batch of appliances and want to quickly get the short list of appliances with no bugs

[qq7]

I found this tool for exploring issues: ghi, which can do just what you described, so probably it's worth just writing a wrapper that would check your current working directory?

By default, it checks all of the issues assigned to your account or current working dir's git repo, but you can adjust repo's git config to use turnkeylinux/tracker, by running
git config ghi.repo turnkeylinux/tracker

So, in products/lamp, running ghi list --label lamp --label bug
will return this:

[JedMeister]

Nice find @qq7 - although FWIW we have a python GH API wrapper: https://github.com/turnkeylinux/octohub It provides both a python library and a commandline tool.

In comparison to the project you found, it's not quite so user friendly as it is just an API wrapper and (as per direct usage of the API) returns JSON data, rather than something a little more easy reading like you posted above. Although FWIW Python is happy to natively work with json and for bash usage there's jq (in the Debian repos FWIW).

Octohub is also a fair bit more flexible as it can also be used to search for pretty much any GitHub "object", such pull requests, etc. For my personal purposes, having the ability to return up-merged PRs would be useful too!

FWIW a while ago, I built a bash script that could run as a cron job and generated html, that tracked bugs, feature requests and open pull requests: https://jedmeister.github.io/tracker/

As you can see, it hasn't been updated for a while. I actually started re-writing it as a python script (the bash script was getting a bit crazy) and extending it a bit (so it also included our custom packages and common pull requests too). Also the "Build Plan" column isn't really relevant any more... But then we updated our versioning scheme to allow individual appliance versions to get out of sync, so one of the assumptions it relied on got broken... I did start updating it to manage that too, but it's been shelved for some time now...

[JedMeister]

It'd also be awesome if this tool (or perhaps another tool to avoid scope creep?) checked the latest appliance (iso) version on the mirror against the top changelog entry.

That would make it easier to know if you need to add a new changelog entry, or edit the existing one! Then we could implement a more strict policy of adding a new changelog entry whenever appliance code was changed (at least if it affects the next build of the appliance.

Re policy, we probably should do that regardless - and perhaps I should open a separate issue... - but this would assist us to implement that.

Speaking of knowing whether a new changelog entry is required, perhaps a command to check the ISO version (as above) against the latest tag too? (to catch applainces that haven't been tagged - probably more useful for me than others). And perhaps even an easy way to get a git diff since the most recent tag (useful for both me when testing and developers when updating changelogs)?

[JedMeister]

FWIW, I've done some work on this but am yet to publish it.

Hopefully I will publish what I've done so far ASAP...

[OnGle]

Would love to see this in action!