A bare-bones command-line bug tracking system for personal or small projects which require little formality.
Add this line to your application’s Gemfile:
And then execute:
Or install it yourself as:
$ gem install beastie
Beastie is a bug tracking system at its bare essentials.
- asks information about an issue and generate a YAML file in the current directory.
- enter a new issue using the default editor (
nedit= new and edit; see
editfor the specificaiton of the editor)
- reads all YAML files in the current directory and generate a list of all the issues.
beastie show N
- shows issue
Nis the identifier shown by the
beastie edit N
- edits issue
N. The commands invokes the editor set in the shell
EDITORvariable or use
- unleashes the real power of
Managing Different Projects
beastie uses the current directory when executing a command. While this makes gives a lot of freedom in choosing one’s standards, it also require a lot of discipline (you always need to make sure you are in the right directory) and can be inconvenient at times.
For this reason, from version 0.3,
beastie supports the following two options to specify the directory to use when executing a command:
--directory) to specify the destination directory
--project) to use a specific project for a directory
-d <dir> (or
--directory <dir>) to specify the directory in which the command is executed.
beastie show -d ~/issues
will show all issues stored in the
-p <name> (or
--project <name>) to specify the name of a project and
beastie will perform the operation on the directory associated to
<name> in the
Entries in the
.beastie_projects file look like:
<name>: dir: <dir> <another name>: dir: <another dir>
For instance, if
beastie: dir: /Users/guest/beastie_issues
$ beastie show -p beastie
will show all the issues stored in the
Use only one of
-p; if you do not,
-d has precedence.
Beastie has support for filtering data, using the
--where option. The option takes as argument an expression (written in Ruby), defining what issues have to be printed.
beastie list --where "status == 'open'"
will show only the
open issues. More complex expressions can be defined, using Boolean operators:
beastie list --where "status == 'open' and priority >= 4"
will show open issues with priority greater or equal to 4.
Notice that the expression passes as argument to
--where is evaluated in Ruby, so any Ruby expression will work.
Since, after the initial excitement, typing
--where "status == 'open'" becomes quite boring, the following shortcuts are available:
--status STATUS, to select by status
--type TYPE, to select by type
the options are put in and. So, for instance:beastie —status open —type bug —where “priority > 3”
will select the open issues, with type bug and priority greater than 3.
Remarks and Warnings
Beastie generates human-readable filenames, following the convention Jekyll has for blog posts. Selecting issues using filenames, however, is a bit clumsy and to simplify operations
beastie assigns a number to each issue, which can be used to reference them. The number can be seen with the
list command and depends upon the order in which issues are listed in the directory. Thus the same issue might be assigned a different id over time, if the order in which files are read changes (e.g., if a new back-dated issue is added by hand).
Beastie does not have a specific workflow for bug statutes.
Beastie does not perform syntax checks when reading data. This can be changed by specifying appropriate input functions in the
ISSUE_FIELDS variable (
Beastie asks various information about a bug. Change the
ISSUE_FIELDS variable, if you are not happy with the default fieldset.
Sorting its on the way (but not yet implemented). Use the power of Unix for that. For instance:
beastie list | grep -v "^ID" | sort -n -k 4
So… why did I re-invent the wheel?
- for fun
- human-readable filenames, so that I can manage issues without using beastie, if I want
- a “programmable” fieldset (see
- keeping the solution simple (280 lines of ruby code, according to
beastie! According to
sloccount, you will be using, for free, a software which costed $4,490 to produce! (This is less than the cost of v 0.3, which was estimated at $8,000. Jekyll mercenary, in fact, lowered the number of lines of code and the costs estimated with COCOMO.)
1. Fork it 2. Create your feature branch (`git checkout -b my-new-feature`) 3. Commit your changes (`git commit -am ‘Add some feature’`) 4. Push to the branch (`git push origin my-new-feature`) 5. Create new Pull Request