- 05 Oct, 2017 1 commit
-
-
Sean McGivern authored
Both `Or` and `And` would evaluate whether each rule passed, then calculate a value based on the results of all of those. We can actually return early in many cases, without running the rule at all.
-
- 04 Oct, 2017 1 commit
-
-
Sean McGivern authored
There were a couple of things here: 1. If the state was already enabled, we don't need to check all the remaining steps - only those that can prevent the state. (An enable followed by an enable is a no-op.) This logic is in `#run`, but we still did the work of scoring and sorting the steps. 2. The sorting is known to be inefficient, but we can make it slightly more efficient by stopping once we have a step with zero score, as that means it's free. Neither of these make this _fast_, especially when called lots of times - as we do when there is lots of activity on an issue - but they do help some.
-
- 15 Aug, 2017 1 commit
-
-
Robert Speicher authored
-
- 14 Aug, 2017 1 commit
-
-
Robert Speicher authored
An upcoming update to rubocop-gitlab-security added additional violations.
-
- 07 Aug, 2017 2 commits
-
-
http://jneen.net/ authored
-
http://jneen.net/ authored
rather than iterating the whole remaining step set with .all?(&:prevent?)
-
- 17 Jul, 2017 2 commits
-
-
http://jneen.net/ authored
-
http://jneen.net/ authored
-
- 27 Jun, 2017 1 commit
-
-
http://jneen.net/ authored
-