New Cil release v0.3.0
Here's another release of cil for your perusal. Staying true to the "Release early, release often" mantra, I hope you have fun playing with it.
I'll quickly go through all the features in this release:
Filters when Listing Issues
For example:
$ cil list --label=Type-Critical $ cil list --status=New $ cil list --assigned-to=andychilton-at-gmail-dot-com
(Note: --label and --status were in v0.2.1.) These can be combined too. For example, this is the command line I used to make sure there were no outstanding issues for this release of cil:
$ cil list --is-open --label=Milestone-v0.3
and opposite to that, for the changelog I could figure out what had changed since the last release by doing this:
$ cil list --is-closed --label=Milestone-v0.3
If I was on a big project, I'd probably cron something like this to send me an email each morning:
$ cil list --is-open --assigned-to=andychilton-at-gmail-dot-com --label=Priority-Critical
That's a pretty nice filter :-)
Added a '.cil' Config File
To be able to do some of the filters above (e.g. --is-open and --is-closed) cil now reads a config file and can determine which statuses and labels are valid. There are also lists to say which statuses are considered open or closed. Of course, if you want neither of features you can just turn them off (which is the default behaviour).
Added a 'fsck' Command
Cil saves it's issues, comments and attachments in the filesystem which isn't usually a good way for (slightly) relational data. The new 'fsck' command can help you figure out missing entities though. For example, if an issue is missing its comments or attachments and whether comments or attachments have been orphaned. It also runs some validation against each issue. Validation at the moment consists of checking statuses and labels in their respective allowed list.
Here is some example output you might see from this command (usually if you or someone else has not been tracking the right things):
=============================================================================== --- Issue c4fa2e27 ----------------------------------------------------------- * StatusStrict is turned on but this issue has an invalid status 'InProg' * LabelStrict is turned on but this issue has an invalid label 'Something' --- Issue 1f67bc27 ----------------------------------------------------------- * comment '8dfe256c' listed in issue '1f67bc27' does not exist * comment '99b20701' is listed under issue '1f67bc27' but does not reciprocate * attachment '29afc3ef' listed in issue '1f67bc27' does not exist =============================================================================== --- Comment 99b20701 --------------------------------------------------------- * comment '99b20701' refers to issue '893f7ea6' but issue does not exist =============================================================================== --- Attachment 37873839 ------------------------------------------------------ * attachment '37873839' refers to issue '8af89d74' but issue does not exist ===============================================================================
More validation checks will be in v0.4.
Bash Completion of Commands, Options and Entities
(Where 'entities' are issues, commands or attachments.)
As stated in a previous post, there is now bash completion for cil.
Working Practices
As I said earlier, I use a few command lines to let me figure out when I can release a version. For example, the next release is going to be v0.4.0 (barring any bug fixes to v0.3.0) so I tag all of the issues I want done for that release with Milestone-v0.4. This makes it easy to see what needs doing and what is already done:
$ cil list --is-open --label=Milestone-v0.4 $ cil list --is-closed --label=Milestone-v0.4
For example, an issue might have been added at some stage in the past, complete with labels:
$ cil add ... added issue 'cafebabe' ...
I usually commit the new issue to my VCS immediately. When I start working on it, I'll mark it InProgress, even if it is just locally. Sometimes I check this in too if it's going to be longer than a few hours:
$ cil status cafebabe InProgress
Once I've finished hacking on the issue and I'm happy with it, I set it to Finished and add a comment to say what I've done:
$ cil status cafebabe Finished $ cil comment cafebabe ... added comment 'decaf7ea' ...
I use Git for my VCS so prior to check in I stage all the working file changes but also make sure Git is tracking the issue properly too. It already knew about the issue file but I need to add the comment file that goes with it:
$ git add issues/c_decaf7ea.cil
Finally when I commit, I commit the code, the issue and the comment all together. In the message I usually put the text '(closes #cafebabe)'. This keeps everything together.
What's Next
The next release of cil will be Milestone-v0.4 so I'll add that label to a few items I want in it. If there is something I want for the future but haven't roadmapped them yet (into v0.5, v0.6 etc) then I just put a Milestone-Future label on them so I know I want to do them but just don't know when.
Happy hacking and look out for v0.4 sometime in the next week or so.
This post originated on http://chilts.org/.
Email me on andychilton -at- gmail -dot- com.