Set feature_category for Geo specs
What does this MR do and why?
Describe in detail what your merge request does and why.
I keep seeing these and doing these myself in other work. Let's avoid wasting time.
Defines feature_category: :geo_replication
on specs which are obviously owned by Geo based on file path.
Methodology
-
Added
feature_category: :geo_replication
to all paths containing the wordgeo
in.rubocop_todo/rspec/missing_feature_category.yml
:require 'yaml' todos = YAML.load_file('/Users/mkozonogitlab/Developer/gdk/gitlab/.rubocop_todo/rspec/missing_feature_category.yml');1 geo_file_paths = todos["RSpec/MissingFeatureCategory"]["Exclude"].select { |path| path =~ %r{geo} };1 geo_file_paths.each { |path| content = File.read(path); content.sub!(" do\n", ", feature_category: :geo_replication do\n"); File.write(path, content) };1
-
Deleted lines containing
geo
in.rubocop_todo/rspec/missing_feature_category.yml
with find and replace- .*geo.*\n
with nothing. -
Manually fixed
Layout/LineLength
violations in a bunch of them. I think the single indentation looks weird, but it is enforced by yet another copLayout/ArgumentAlignment
. At least it is consistent, so I am sure I will get used to it. -
Removed
:geo
tag when I fixed line length, since it is not needed anyway, because CI also categorizes specs as Geo if they are in ageo
directory. -
Manually added
feature_category
toee/spec/finders/geo_node_finder_spec.rb
(IDK why I needed to do this).
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.