The plan stage both measures time taken and lists related commits. We test for commits being listed, so needed to actually mention the issue in them. An alternative would have been adding “allow_any_instance_of(Commit).to receive(:matches_cross_reference_regex?).and_return(true)” but this felt too coupled to implementation.
FFaker can generate data that randomly break our test suite. This
simplifies our factories and use sequences which are more predictive.
Signed-off-by: Rémy Coutable <remy@rymai.me>
disable markdown in comments when referencing disabled features
fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/23548
This MR prevents the following references when tool is disabled:
- issues
- snippets
- commits - when repo is disabled
- commit range - when repo is disabled
- milestones
This MR does not prevent references to repository files, since they are just markdown links and don't leak
information.
See merge request !2011
Signed-off-by: Rémy Coutable <remy@rymai.me>
- The commit count was capped at 10, due to
`Gitlab::Git::Repository#log` enforcing a limit, with the default set
to 10.
- Reimplement a small portion of this `log` function to get just the
data we need.
1. Move the test generation to `CycleAnalyticsHelpers::TestGeneration`
2. Move all helper methods (previously placed in each individual spec
file) to `CycleAnalyticsHelpers`
Add a `before_end_fn` option to the code that generates cycle analytics
specs. `before_end_fn` is called before the end conditions are. Used for
data setup that needs to be called after the start conditions and before
the end conditions.
Remove overlap from the "start + end" durations in the happy test
case. For the `staging` phase, the end time is the _first_ deployment
that happens after the MR merge.
If we have 5 MRs where the `start_time`s (merge time) are the
same, and all the `end_time`s (deploy to production) a few days from
now, only the earliest deploy will get picked up, because that
consitutes a deploy for _all_ the MRs.
We fix this by removing overlap. Every `start_time` is now generated to
be _after_ the preceding `end_time`.
1. Generalise the specs that will be common across all cycle analytics
phases.
2. Rewrite specs `issue` and `plan` to use this abstracted testing
strategy.
3. Specs that are specific to a given phase, or unwieldy to test in an
abstracted manner, are added to each phase's spec.
