Hundreds of builds after branch rebase

[tankist]

As all rebased commits have new hashes PHPCI consider them as new commits and creates a lot of pending builds.

I propose to discuss how to figure out such situation. Possible solutions:

1. Put on hold more then n commits from the same branch if they come together. So user will manually decide what to do.
2. Analyze commit messages with soundex and levenstein and mark them as "Skipped" becasue of duplicates

Something else?

[Patabugen]

This is a feature I'd very much like, and would be interested in attempting to implement it subject to a discussion on exactly what "it" is.

Jenkins calls this a "Quiet Period", basically it delays triggering anything until X minutes after the last commit (per branch, I presume).

http://jenkins-ci.org/content/quiet-period-feature

Comments on @tankist 's suggestions:

1. I would say only run on the latest commit in a burst, but perhaps have an option to manually run on an earlier branch in case it's useful to someone to know (from their CI instead of VC) exactly when something was introduced. For me it wouldn't be useful, as a burst of commits on a branch would (should?) represent a fairly small number of features. I wish to setup PHPCI to run my functional testing, a suite which takes ~30 minutes to run. For this main reason, I certainly wouldn't want to run for every commit.
2. I love the idea of this! Although I don't think it'll be used in conjunction with a quiet time.

Perhaps we need two options, tasks to run on every commit and tasks to run only after a burst of commits? The former would use your suggestion #2 to reduce the number of runs.

For example:

• Every Commit: unit tests, code sniffing, syntax checking, code standards
• Every Burst: technical debt, functional testing

[asgrim]

I believe this is a duplicate of #656?