[VSA] Fixture raises NoMethodError outside of CI context

Problem to solve

The VSA fixture (db/fixtures/development/17_cycle_analytics.rb) is erroring due to a NoMethodError. The method is allow, which is not available outside the CI context. Inside the CI context the fixture can be run successfully, which is why we were not aware of this error.

Proposal

Stop using test factories in the fixture.

Related links

• This was reported in Slack#g_manage_analytics on 2020-09-04:

Partial trace

== Seed from /Users/mlunoe/workspace/gdk/gitlab/db/fixtures/development/17_cycle_analytics.rb ************************************************** ️ WARNING: Sidekiq testing API enabled, but this is not the test environment. Your jobs will not go to Redis. ************************************************** rake aborted! NoMethodError: undefined method `allow' for # /Users/mlunoe/workspace/gdk/gitlab/spec/factories/merge_requests.rb:257:in `block (3 levels) in ' (eval):89:in `block in seed_code_stage!' (eval):88:in `each' (eval):88:in `seed_code_stage!' (eval):55:in `seed!' (eval):204:in `block (3 levels) in run_file' /Users/mlunoe/workspace/gdk/gitlab/lib/gitlab/seeder.rb:90:in `quiet' (eval):197:in `block (2 levels) in run_file' /Users/mlunoe/.rbenv/versions/2.6.6/bin/bundle:23:in `load' /Users/mlunoe/.rbenv/versions/2.6.6/bin/bundle:23:in `' Tasks: TOP => db:seed_fu (See full trace by running task with --trace)

added backend devopsmanage groupoptimize severity3 typebug workflowsolution validation labels

added sectiondev label

mentioned in issue #246441 (closed)

marked this issue as related to #235734 (closed)

I would still use the factories because we can reduce significant amount of work when creating DB records. I'll try to figure something out to workaround the missing allow method failure.

For some reason I cannot reproduce the error (master):

> $ FILTER=cycle_analytics SEED_CYCLE_ANALYTICS=1 bundle exec rake db:seed_fu                                           

== Filtering seed files against regexp: /cycle_analytics/

== Seed from/gitlab-development-kit/gitlab/db/fixtures/development/17_cycle_analytics.rb
**************************************************
⛔️ WARNING: Sidekiq testing API enabled, but this is not the test environment.  Your jobs will not go to Redis.
**************************************************

Successfully seeded 'vsmg-1599628982/vsmp-1599628982' for Value Stream Management!
URL: http://127.0.0.1:3000/vsmg-1599628982/vsmp-1599628982

OK

== Seed from ee/db/fixtures/development/30_customizable_cycle_analytics.rb
Skipped. Use the `SEED_CUSTOMIZABLE_CYCLE_ANALYTICS` environment variable to enable.

OK

Hmmm... I got this (failed on first run and succeeded thereafter!) :thinking::

➜  gitlab git:(master) ✗ FILTER=cycle_analytics SEED_CYCLE_ANALYTICS=1 bundle exec rake db:seed_fu     

== Filtering seed files against regexp: /cycle_analytics/

== Seed from /Users/mlunoe/workspace/gdk/gitlab/db/fixtures/development/17_cycle_analytics.rb
**************************************************
⛔️ WARNING: Sidekiq testing API enabled, but this is not the test environment.  Your jobs will not go to Redis.
**************************************************
rake aborted!
ActiveRecord::RecordNotUnique: PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint "merge_requests_pkey"
DETAIL:  Key (id)=(11) already exists.
(eval):89:in `block in seed_code_stage!'
(eval):88:in `each'
(eval):88:in `seed_code_stage!'
(eval):55:in `seed!'
(eval):204:in `block (3 levels) in run_file'
/Users/mlunoe/workspace/gdk/gitlab/lib/gitlab/seeder.rb:90:in `quiet'
(eval):197:in `block (2 levels) in run_file'
/Users/mlunoe/.rbenv/versions/2.6.6/bin/bundle:23:in `load'
/Users/mlunoe/.rbenv/versions/2.6.6/bin/bundle:23:in `<main>'

Caused by:
PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint "merge_requests_pkey"
DETAIL:  Key (id)=(11) already exists.
(eval):89:in `block in seed_code_stage!'
(eval):88:in `each'
(eval):88:in `seed_code_stage!'
(eval):55:in `seed!'
(eval):204:in `block (3 levels) in run_file'
/Users/mlunoe/workspace/gdk/gitlab/lib/gitlab/seeder.rb:90:in `quiet'
(eval):197:in `block (2 levels) in run_file'
/Users/mlunoe/.rbenv/versions/2.6.6/bin/bundle:23:in `load'
/Users/mlunoe/.rbenv/versions/2.6.6/bin/bundle:23:in `<main>'
Tasks: TOP => db:seed_fu
(See full trace by running task with --trace)
➜  gitlab git:(master) ✗ FILTER=cycle_analytics SEED_CYCLE_ANALYTICS=1 bundle exec rake db:seed_fu --trace
** Invoke db:seed_fu (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:seed_fu

== Filtering seed files against regexp: /cycle_analytics/

== Seed from /Users/mlunoe/workspace/gdk/gitlab/db/fixtures/development/17_cycle_analytics.rb
**************************************************
⛔️ WARNING: Sidekiq testing API enabled, but this is not the test environment.  Your jobs will not go to Redis.
**************************************************
Successfully seeded 'vsmg-1599656861/vsmp-1599656861' for Value Stream Management!
URL: http://127.0.0.1:3000/vsmg-1599656861/vsmp-1599656861

OK

== Seed from ee/db/fixtures/development/30_customizable_cycle_analytics.rb
Skipped. Use the `SEED_CUSTOMIZABLE_CYCLE_ANALYTICS` environment variable to enable.

OK

@mlunoe seems like the PG::UniqueViolation error you encountered is a different issue than the NoMethodError problem. I suspect it was because you ran the migrations after already having some data in your database. That's based on the error message you encountered ("Key (id)=(11) already exists") and understanding migrations were successful on the second attempt. But I assume you cleared the database before that second attempt, right?

@djensen I think that is what I did to resolve it, but I honestly can't remember anymore

@mlunoe fair enough, sorry for taking so long to reply!

@ahegyi you were not able to replicate and I don't believe we have received other reports of this. Do you think this problem was temporary or related to a specific upgrade? I'm wondering if we could close

@djensen All good. Yeah, I think it is safe to close. We can always re-open if somebody runs into this again

mentioned in issue #249042 (closed)

mentioned in issue #254143 (closed)

mentioned in issue #257769 (closed)

mentioned in issue #261976 (closed)

mentioned in issue gitlab-org/quality/triage-reports#470 (closed)

mentioned in issue gitlab-org/quality/triage-reports#530 (closed)

marked this issue as related to #262861 (closed)

removed the relation with #262861 (closed)

mentioned in issue #270402 (closed)

mentioned in issue gitlab-org/quality/triage-reports#606 (closed)

mentioned in issue gitlab-org/quality/triage-reports#665 (closed)

mentioned in issue gitlab-org/quality/triage-reports#672 (closed)

mentioned in issue gitlab-org/quality/triage-reports#705 (closed)

mentioned in issue gitlab-org/quality/triage-reports#794 (closed)

mentioned in issue gitlab-org/quality/triage-reports#853 (closed)

mentioned in issue gitlab-org/quality/triage-reports#943 (closed)

mentioned in issue gitlab-org/quality/triage-reports#1017 (closed)

@ahegyi in our 1:1 earlier today we talked about that other recent problem with migrations in the GDK context, where clearing the Gitaly cache fixed the problem. But I don't think that would fix the NoMethodError here.

changed due date to December 03, 2020

@ljlane I just set the due date on this ~bug issue to reflect our 90-day SLO on severity3 bugs. Coincidentally it was yesterday (2021-12-03), so we should probably consider this as one of the bugfixes we include for %13.8 or %13.9.

I'm good with adding this to %13.8 @djensen, especially considering we are currently light on backend work for %13.8

changed milestone to %13.8

removed milestone %13.8

mentioned in issue gitlab-org/quality/triage-reports#1081 (closed)

Closing this per this: #245320 (comment 462567403)

closed

added devopsmonitor label and removed devopsfoundations label