ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Fixing an issue via commit message is not updated until visinging the repo tab (Bug #769)
Description
We have setup Chiliproject to integrate with a Git repository per project, which works just fine. The only annoyance we currently have is that when a commit message contains one of the "Fixing keywords" as defined in the Administration settings, the issue status is not updated until a user opens the repository tab.
Once someone visits the repository tab, the issue is updated ( shows as fixed on the commit history from the first page load ).
Is this a known problem (couldn't find a related issue via search)? Is there a way around it? We would definently love to have this handy feature working. If there is any more information I can provide to assist, please let me know.
If it's of any help, we're currently at ChiliProject 2.4.0.ee543489f (Mysql2)
History
Updated by Felix Schäfer at 2011-12-16 11:23 am
This is indeed a known "problem" in that ChiliProject is a request-driven web app and doesn't have a background worker to poll the repositories, thus polling the repositories is done by default only when you visit the corresponding repository page.
There are ways to mitigate that though, one is cron-based and addressed in the FAQ, the other is based on a post-commit hook added to your repositories. I think there's some docs/wiki/forum post about that, though I can sum it up for you if you can't find it.
- Status changed from Open to Declined
Updated by Nick Andriopoulos at 2011-12-16 12:03 pm
For future reference, afore-mentioned thread with info is https://www.chiliproject.org/issues/57#note-4
Only question - since in our specific case both repos and Chiliproject live on the same host, is there a reason not to run the cron command in the post-commit hook?
It appears to be working as expected.
Thank you in advance.
- Status changed from Declined to Closed
Updated by Felix Schäfer at 2011-12-16 12:08 pm
Nick Andriopoulos wrote:
Only question - since in our specific case both repos and Chiliproject live on the same host, is there a reason not to run the cron command in the post-commit hook?
It appears to be working as expected.
The rake command starts a whole new process and has the usual rails "cold start" tax and iterates over all repositories, which can take a long time and cost resources. The call to /sys/fetch_changesets in the other hand queries only the repository that's updated and uses a free (and most of time already running, depending on your app server) web worker instead of starting a whole new process.