Remove explicit use of MiniCache::Data
What does this MR do and why?
Set expires_in
in MiniCache#get_or_set
or MiniCache#set
explicitly
which simplifies the code.
How to verify locally?
Since we are missing (some) specs for these changes I've verified via rack-console
:
$ GITLAB_API_ENDPOINT=https://gitlab.com GITLAB_COM_API_TOKEN=$GITLAB_API_PRIVATE_TOKEN bundle exec rack-console
Loading development environment (Rack::Console 1.3.1)
[1] pry(main)> Triage::GROUP_CACHE_DEFAULT_EXPIRATION = 2
(pry):1: warning: already initialized constant Triage::GROUP_CACHE_DEFAULT_EXPIRATION
/home/peter/devel/gitlab/triage-ops/triage/triage.rb:20: warning: previous definition of GROUP_CACHE_DEFAULT_EXPIRATION was here
=> 2
[2] pry(main)> [1, 1, 1, 1].each { |i| p Triage.gitlab_com_support_member_ids.object_id; sleep i }
51980
51980
52000
52000
=> [1, 1, 1, 1]
[3] pry(main)> WwwGitLabCom::DATA_CACHE_DEFAULT_EXPIRATION = 2
(pry):5: warning: already initialized constant WwwGitLabCom::DATA_CACHE_DEFAULT_EXPIRATION
(pry):3: warning: previous definition of DATA_CACHE_DEFAULT_EXPIRATION was here
=> 2
[4] pry(main)> [1, 1, 1, 1].each { |i| p WwwGitLabCom.categories.object_id; sleep i }
52060
52060
52080
52080
=> [1, 1, 1, 1]
Expected impact & dry-runs
These are strongly recommended to assist reviewers and reduce the time to merge your change.
See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.
See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.
Action items
-
If adding environment variables for reactive processors, update config/triage-web.yaml
and.gitlab/ci/triage-web.yml
-
(If applicable) Add documentation to the handbook pages for Triage Operations => - (If applicable) Identify the affected groups and how to communicate to them:
-
/cc @ person_or_group
=> -
Relevant Slack channels => -
Engineering week-in-review
-
Edited by Peter Leitzen