Scan recently active branches (and only them) for commits.
Issue #9 addresses the problem of scanning 'all branches' so that it is not necessary to configure each and every branch individually via UI.
However it introduces another problem -- in a repository with a lot of branches it will unnecessarily scan all of them every time regardless of whether they are active or not.
Consider adding another option that only scans 'recently active' branches for changes as discussed in issue #9 comments.
Comments (6)
-
repo owner -
reporter I don't really know enough of Gitlab and Jira to make any definite statements.
But the way I see it:
-
Pushing from the gitlab side is nice optimization -- I assume commits can be picked up earlier and generally speaking there's less overhead.
-
I have no idea how much configuration and where will be required to make it happen -- but this is potentially a significant annoyance.
-
I suspect the actual performance savings compared to just scanning recent branches will be quite modest (i.e. I don't see this as 'must have' option).
-
But most importantly I think that relying only on 'push' is not a viable approach. Whenever there are systems that depend on notifications ('push' etc.) I always ask myself "What is going to happen if notification gets lost/mishandled? How do we ensure that the 'receiver' side can 'sync' itself back again after an error/outage?"
So even if 'push/webhooks' are implemented, I don't think it is realistic to expect to 'stop using scanning at all'. I think scanning will still be necessary (and probably will need to be run quite regularly) just to make sure that there are no missed updates.
-
-
repo owner Thanks for such a comprehensive answer.
-
repo owner -
assigned issue to
-
assigned issue to
-
reporter Any chance for this? I'd rather replace my crude hack with the 'official' version :)
I think one concern was that GitHub doesn't support this -- but then the code could fallback to just scanning all branches for GitHub?
-
repo owner Hi Sergey,
Issue is not closed so someday it'll be implemented.
- Log in to comment
Hi! Yesterday we talked about problems with tons of legacy branches. You've offered the decision above based on the core Jigit approach: indexing GitLab via it's API . Actually, there is another way: to use GitLab webhooks. In this case GitLab will notify Jigit about new commits and we can stop using scanning at all. Would you use this schema if webhook reciever were implemented in Jigit? Are you interested in this feature?