You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Imagine PHPCI WebHook is called, and the code queues 3 inspections. Then the scheduled task begins with the 1st one (building x1 inspection + x2 inspections queued).
Then we push a new commit, and PHPCI queues this one too (building x1 + x3 inspections queued). Given we have pushed a new commit, does not make sense to keep the other 2 inspections (as far they are using the same branch).
IMO ideally the process should cancel the queued inspections and keep just the last one.
The text was updated successfully, but these errors were encountered:
Same answer as your previous question. The idea of CI is to find when something breaks.
If you keep skipping running builds when new commits are pushed then you'll end up thinking the last commit was the one breaking the build.
Here's what would happen if PHPCI cancelled builds:
I push some bad code that's going to break the build.
Build runs.
You push some valid code.
Build is cancelled and a new build is run against latest code base.
Build fails because of my code but PHPCI will report that your changes caused the build to fail.
You're going to waste time finding your mistake when I should be the one investigating!
Imagine PHPCI WebHook is called, and the code queues 3 inspections. Then the scheduled task begins with the 1st one (building x1 inspection + x2 inspections queued).
Then we push a new commit, and PHPCI queues this one too (building x1 + x3 inspections queued). Given we have pushed a new commit, does not make sense to keep the other 2 inspections (as far they are using the same branch).
IMO ideally the process should cancel the queued inspections and keep just the last one.
The text was updated successfully, but these errors were encountered: