You're using hamster to track your work? let your hamster log your work to your favorite bug tracker. ok, JIRA & Redmine for now :)
As you probably installed hamster via your systems package manager you should install this python package to your root python environment or (and that is recommended) create a virtualenv with system-packages (to ensure this package can talk to the hamster instance).
create virtualenv with system packages::
virtualenv --system-site-packages path/to/hamster-bridge-env
source path/to/hamster-bridge-env/bin/activateinstall via pip::
pip install hamster-bridgethen run it with::
hamster-bridge jirainstall via pip::
pip install hamster-bridge[redmine]then run it with::
hamster-bridge redmineIt will ask you for your server and login and will save that data for next starts in :code:~/.hamster-bridge.cfg.
When you stop, the hamster-bridge becomes active and search for a valid ticket name. For JIRA that's something like
"ABC-34" (the actually regex is [A-Z][A-Z0-9]+-[0-9]+). It will search the title first, when there's none, it
looks into the tags. It will use the issue name only when it really exists, f.e. in a task with the title "Fixing the
STUDIO-54 error message" with the tag "DISCO-433", there will be an existence check of "STUDIO-54", if it does not exist
it will read through to issue in the tag.
Once one valid ticket is found, the hamster-bridge will log the spent time to this issue together with the hamster
task description as comment.
Since version 0.6 by default no sensitive data is stored in the config file
(e.g. :code:~/.hamster-bridge.cfg). Currently the only data marked as
sensitive is the JIRA password.
Every time you start the application it will use all values found in the config file and interactively ask you for the missing values (e.g. JIRA password).
If you want to force saving this sensitive data in the config file you can use the --save-passwords option. You can also manually add the data to the config file. If you are upgrading from an older version of hamster-bridge (where all data was stored in the config file by default) then it will continue to work like before because all required values are in the config file.
The verify_ssl config entry has 3 possible values: 'y' to enable certificate verification with the default CA, 'n' to disable certificate verification (not recommended!) and the path to a CA (Certificate Authority) bundle containing SSL/TLS certificates. When setting a path use the full path to prevent errors.
This is very valuable if the CA store that your Python environment uses by default does not include the CA or intermediate CA that signed the certificate of your JIRA/Redmine site. This is also the case if your JIRA/Redmine site uses a self-signed certificate.
How to set it up? Get your certificate or certificate chain and store it in a file. Specify the path to that file in the config.
For instance your can do this with Google Chrome by:
If your JIRA/Redmine site uses a certificate signed by a globally trusted root CA you might want to try using a standard CA bundle. For example:
certifi bundle <https://certifi.io/en/latest/>_ and use itFor Redmine the verify_ssl option existed already and has been extended to also allow you to specify a CA cert bundle path. If you had previously specified y/n in the config it will continue to work as before.
If verify_ssl is set to an unknown value or to an invalid path then the fallback is SSL/TLS certificate verification with the default CA bundle.
It is possible both for JIRA and Redmine to 'auto start' (i.e. mark as in progress or something equivalent) an issue when you start tracking time for it.
Simply set the corresponding config option to 'y' to activate auto start and to 'n' to disable it.
In the case of JIRA a third value is possible. This value implicitly assumes 'y' and uses the value you set as the name of the transition. For example if you want to use the transition 'Working' you can set the config value to precisely that value. The same goes if you want to the set the transition to 'In Progress'. Per default 'Start Progress' is used (i.e. when you specify 'y').
Don't work for you? Open up an issue on GitHub <https://github.com/kraiz/hamster-bridge/issues>_ together with the
debug output (start the bridge with "-d").
Redmine behaves slightly different than JIRA. For each time entry that is created, an activity has to be chosen. Within the Redmine installation a default activity can be defined but usually this is not the way the installation is set up. Therefore one must be able to select the activity when creating a time entry. As the hamster does not offer any field for such activity, we instead use the tags field. Upon start of the hamster-bridge, all activities will be listed::
2015-03-01 14:23:31,003 INFO: ### Available Redmine activities for using as tag value:
2015-03-01 14:23:31,229 INFO: ### Development
2015-03-01 14:23:31,229 INFO: ### Design
2015-03-01 14:23:31,230 INFO: ### DeploymentIf you set the name of an activity as tag, it will be used for the created time entry. If you do not specify a tag, the first activity (and usually the default one in Redmine) will be used. If you specify more than one activity as tag value, the first found will be used (but see the hints below!). You can mix the activity tags with other tags - the first found tag that matches the name of an activity will be used for the entry (see the hints, too).
Important hints:
MIT-License, see LICENSE file.