/home/ubuntu/valkyrie/valkyrie/.rubocop.yml: Style/PredicateName has the wrong namespace - should be Naming
/home/ubuntu/valkyrie/valkyrie/vendor/valk_bundle/ruby/2.3.0/gems/bixby-0.2.2/bixby_default.yml: Style/AccessorMethodName has the wrong namespace - should be Naming
/home/ubuntu/valkyrie/valkyrie/vendor/valk_bundle/ruby/2.3.0/gems/bixby-0.2.2/bixby_default.yml: Style/AsciiIdentifiers has the wrong namespace - should be Naming
/home/ubuntu/valkyrie/valkyrie/vendor/valk_bundle/ruby/2.3.0/gems/bixby-0.2.2/bixby_default.yml: Style/ClassAndModuleCamelCase has the wrong namespace - should be Naming
/home/ubuntu/valkyrie/valkyrie/vendor/valk_bundle/ruby/2.3.0/gems/bixby-0.2.2/bixby_default.yml: Style/ConstantName has the wrong namespace - should be Naming
/home/ubuntu/valkyrie/valkyrie/vendor/valk_bundle/ruby/2.3.0/gems/bixby-0.2.2/bixby_default.yml: Style/FileName has the wrong namespace - should be Naming
/home/ubuntu/valkyrie/valkyrie/vendor/valk_bundle/ruby/2.3.0/gems/bixby-0.2.2/bixby_default.yml: Style/MethodName has the wrong namespace - should be Naming
/home/ubuntu/valkyrie/valkyrie/vendor/valk_bundle/ruby/2.3.0/gems/bixby-0.2.2/bixby_default.yml: Style/PredicateName has the wrong namespace - should be Naming
/home/ubuntu/valkyrie/valkyrie/vendor/valk_bundle/ruby/2.3.0/gems/bixby-0.2.2/bixby_default.yml: Style/VariableName has the wrong namespace - should be Naming
/home/ubuntu/valkyrie/valkyrie/vendor/valk_bundle/ruby/2.3.0/gems/bixby-0.2.2/bixby_default.yml: Style/VariableNumber has the wrong namespace - should be Naming
Error: The `Style/OpMethods` cop has been renamed and moved to `Naming/BinaryOperatorParameter`.
(obsolete configuration found in /home/ubuntu/valkyrie/valkyrie/vendor/valk_bundle/ruby/2.3.0/gems/bixby-0.2.2/bixby_default.yml, please update it)

Should we be defining rubocop versions?

Descriptive summary

For Bixby v4.0.0, the error below occurs when attempting to build an application (in this case, Hyrax bl7bootstrap4 branch) that runs off of Ruby 2.7.4.

Error: unrecognized cop or department Lint/UselessElseWithoutRescue found in vendor/bundle/ruby/2.7.0/gems/bixby-4.0.0/bixby_default.yml
Did you mean `Lint/UselessSetterCall`?

After researching, I found that the latest version of Rubocop (a Bixby dependency) has removed this Cop because Ruby v2.6+ has stopped allowing the use of begin...else syntax. Reference: rubocop/rubocop#10577

Rationale

The presence of Lint/UselessElseWithoutRescue in the bixby_default.yml file is preventing the application building process.

Descriptive summary

This repository’s default branch has already been renamed using GitHub’s renaming tool. Links that reference the old branch name are automatically forwarded to the new default branch. But string references are not automatically updated.

Check this repository for hard-coded string references to the legacy “master” default branch and update them to the new default branch name “main.”

Important places to check include, but are not limited to:

• READMEs
• wikis
• other documentation

NOTE: READMEs, wikis, and other documentation are important to update to avoid confusion and correct errors in long lasting documentation.

Less common places to check:

• code
• Issues/PRs

NOTE: String references to themaster branch in Issues, PRs, and code are uncommon. Also Issues and PRs are temporal in nature, making it less critical to update those occurrences.

Rationale

Git's default "master" branch derives from "master/slave" jargon which perpetuates systemic racist language and systems (see email Replacing "master" reference in git branch names). To uphold our Code of Conduct, we must move away from the term "master" in our technical language (as well as words like blacklist or whitelist).

Related work

• Background on the renaming effort is available in the working group notes.
• See the GitHub Renaming documentation for the changes that GitHub made during the renaming process.

The Bixby config is not compatible with newer rubocop:

Error: The `Style/TrailingCommaInLiteral` cop no longer exists. Please use `Style/TrailingCommaInArrayLiteral` and/or `Style/TrailingCommaInHashLiteral` instead.
(obsolete configuration found in /Users/jcoyne/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/bixby-1.0.0/bixby_default.yml, please update it)
The `Performance/HashEachMethods` cop has been removed since it no longer provides performance benefits in modern rubies.
(obsolete configuration found in /Users/jcoyne/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/bixby-1.0.0/bixby_default.yml, please update it)
The `Style/MethodMissing` cop has been split into `Style/MethodMissingSuper` and `Style/MissingRespondToMissing`.
(obsolete configuration found in /Users/jcoyne/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/bixby-1.0.0/bixby_default.yml, please update it)

https://docs.rubocop.org/rubocop/0.85/versioning.html#pending-cops explains how rubocop has adopted a better approach to newly added cops instead of the new cops on by default that was part of if not the main driver for creating bixby. Is there still enough value in a shared style configuration to justify maintaining bixby? If so, how should bixby make use of this new policy? Should the NewCops cop be disabled? How often should new cops be integrated and major releases cut?

In a Rails project, I sometimes move ruby source files to my tmp dir to stash them for later. When I run rubocop, I get false failures coming from the tmp dir.

Can we add an exclusion to the AllCops so that rubocop will ignore anything under tmp?

Add the following branch renaming language to the README for this repository.

## Contributing 

If you're working on a PR for this project, create a feature branch off of `main`. 

This repository follows the [Samvera Community Code of Conduct](https://samvera.atlassian.net/wiki/spaces/samvera/pages/405212316/Code+of+Conduct) and [language recommendations](https://github.com/samvera/maintenance/blob/master/templates/CONTRIBUTING.md#language).  Please ***do not*** create a branch called `master` for this repository or as part of your pull request; the branch will either need to be removed or renamed before it can be considered for inclusion in the code base and history of this repository.

Rationale

Git's default "master" branch derives from "master/slave" jargon which perpetuates systemic racist language and systems (see email Replacing "master" reference in git branch names). To uphold our Code of Conduct, we must move away from the term "master" in our technical language (as well as words like blacklist or whitelist).

Related work

• Background on the renaming effort is available in the working group notes.
• See the GitHub Renaming documentation for the changes that GitHub made during the renaming process.

FactoryGirl gives deprecation warnings telling us to use FactoryBot/AttributeDefinedStatically cop to fix the deprecations:

https://travis-ci.org/samvera/hyrax/jobs/417432846#L3205

DEPRECATION WARNING: Static attributes will be removed in FactoryBot 5.0. Please use dynamic
attributes instead by wrapping the attribute value in a block:
with_permission_template { false }
To automatically update from static attributes to dynamic ones,
install rubocop-rspec and run:
rubocop \
  --require rubocop-rspec \
  --only FactoryBot/AttributeDefinedStatically \
  --auto-correct

However, this cop doesn't exist in rubocop-rspec 1.22.2. The latest version is 1.29.0

As discovered by @fnibbit, @bess, and @randalldfloyd, there are a number of Core Components which depend upon this Gem. I can look to ensure that this meets all requirements set forth by https://samvera.github.io/core_components.html#requirements-for-a-core-component

I have been working within the Hyku codespace for a little while and have been struggling with the higher character limit that you permit for each line of code - I believe this is currently set to 200 characters per line.

As someone who struggles periodically due to mild dyslexia, incredibly long lines of code are far harder to comprehend in their entirety than those which have been broken up for brevity.

I will provide an example below and please note I mean no disrespect to the owner of this code, it is only used because of its length of 184 characters - 16 character below your upper limit:

if Hyrax::PresenterFactory.build_for(ids: [collection.thumbnail_id], presenter_class: Hyrax::FileSetPresenter, presenter_args: [current_ability, request]).first&.solr_document&.public?

If this were broken up so that the options for the build_for method were on a seperate line, the entire condition can be much more easily comprehended:

options = { 
    ids: [collection.thumbnail_id], 
    presenter_class: Hyrax::FileSetPresenter, 
    presenter_args: [current_ability, request] 
} 
if Hyrax::PresenterFactory.build_for(options).first&.solr_document&.public?

Thank you.

Getting this warning when I run rubocop with bixby 0.3.0. rubocop still completes and passes.

Derived from samvera/maintenance#89

The maintenance template for CONTRIBUTING.md is used by all Samvera repos. Replace the current version with the updated maintenance template version.

This is derived from samvera/maintenance#119, and follows the guide in https://guides.rubygems.org/mfa-requirement-opt-in/

See: samvera/hyrax#2655 (comment)

The Renaming Branch Working Group is in the process of renaming the default branch from master to main in Samvera and Samvera-Labs repos. This brings repositories into compliance with the Samvera Community Code of Conduct (https://samvera.atlassian.net/wiki/spaces/samvera/pages/405212316/Code+of+Conduct) and language recommendations (https://github.com/samvera/maintenance/blob/master/templates/CONTRIBUTING.md#language).

This issue will be complete when the master has been renamed to main.

Related issues will have a title beginning with RENAME.

This follows the proposed maintenance reorganization within samvera/maintenance#137

Starting a new Hyrax project on bixby, I found I needed to introduce only two exceptions to the style guide here to get to green CI (after rubocop:auto_correct). Both are related to the length of CatalogController` and its internal blocks.

The proposed rule would be something like:

Metrics/BlockLength:
  Exclude:
    - 'config/**/*'
    - '**/*/catalog_controller.rb'

Metrics/ClassLength:
  Exclude:
    - '**/*/catalog_controller.rb'

See: curationexperts/epigaea@d76c5f1#diff-11a0d7906801d9dea0eccb85667ad811R4

This is required of https://samvera.github.io/samvera_labs.html#guidelines-for-promotion-to-samvera-from-labs in order to promote this as a core component (please samvera/maintenance#50).

Descriptive summary

This repository’s default branch has already been renamed to main using GitHub’s renaming tool. In order to preserve automatic redirection of links that reference the old branch name master to the new default main branch, a branch with the old name should not be recreated.

CircleCI can be used to prevent the recreation of the old default branch name by preventing PRs with a branch named master from being merged by causing a test failure during continuous integration.

Rationale

Git's default "master" branch derives from "master/slave" jargon which perpetuates systemic racist language and systems (see email Replacing "master" reference in git branch names). To uphold our Code of Conduct, we must move away from the term "master" in our technical language (as well as words like blacklist or whitelist).

Expected behavior

If a PR is submitted with a branch named master, the continuous integration tests should fail.

Actual behavior

If a PR is submitted with a branch named master, the continuous integration tests will not fail because of the branch name.

Related work

Background on the renaming effort is available in the working group notes.

When setting up codeclimate, I've had to configure codeclimate to fetch the bixby configs and then reference them locally since bixby_default.yml locally inherits from the other two configs. It would be nice to skip the fetching and use inherit_from with the uri to the bixby configs hosted on github. Documentation supporting this use case would be nice.

This unfortunately does appear to abort the rest of the rubocop run and fail the test suite.

Dropping Ruby 2.5 support would break the latest stable releases of Hyrax

Changes following 1c227e1 should be tracked and prepared for a new release.