Scan recently active branches (and only them) for commits.

Issue #11 new
Sergey O. created an issue

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)

  1. Dmitrii Apanasevich repo owner

    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?

  2. Sergey O. 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.

  3. Sergey O. 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?

  4. Log in to comment