This error happen in a CI run, and as it is currently, it doesn't give
any useful information about the underlying cause. Let's not swallow the
original error.
8c17ba2f45
The newly added specs needs to be tagged as
:readline, otherwise they fail on Windows with
the backtrace: `ZeroDivisionError: divided by 0`.
Such issues are already being skipped on Windows.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
391f860af4
Since this PR was made because we missed checking
RuboCop offenses with different flags, therefore
adding tests so that all flag combinations are
tested.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
d08250efc2
The Gemfile wasn't properly put in the last commit.
As a result, Layout/EmptyLines inspected an offense
in the Gemfile.
This also fixes the spec w.r.t change in the task
default.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
d1418fddd3
If the blank lines aren't used, then rubocop tries to
sort them in alphabetical order within their section.
Thus, adding lines so rubocop considers them as
different sections and doesn't try to sort them.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
cf44b18f0f
In case of multiple Rake tasks, the default tasks would
look something like this:
`task default: [:spec, :rubocop]`
Instead, they should use %i and look something like this:
`task default: %i[spec rubocop]`
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
487ecd59ce
With #3731 and #3740 merged, this covers up the
remaining part of the issues.
This was discovered when one tries to create a gem
with a different framework.
Could be reproduced with:
`bundle gem foo --ext --test=test-unit`
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
51b6457150
Right now, we're not specifying the version constraints
on RuboCop that is shipped when a new gem is created.
This can break specs which runs rubocop on a new
skeleton gem as the newer versions of RuboCop are
released.
This commit ensures that the specs don't break by
constraining the RuboCop version.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
0b47243edd
It simplifies things and should avoid issues like the one we had where
the master branch had a bad `.gitattributes` file and changing it on a
PR would be disregarded.
In order for this to work, we need to make sure to fetch all tags from
the repository, so that they can properly be checked out later. This
does not apply to the case of testing against `RGV=..`, since no extra
cloning is needed there.
d088d936b8
ruby_core has an 'ast.rb' file that gets in the
middle and breaks this spec, so it's better we skip
this test on this workflow for now.
Also, slightly change the spec name from "run" to
"runs" and change the last assertion, it's cleaner
to check empty error.
Thanks to David Rodríguez for this!
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
ba8eaa70c3
With older versions of rubocop, the dependency on
`jaro_winkler` seems to be a pain.
However, in the later versions of rubocop, this
dependency was dropped. So we only need to use
the older version for ruby2.3.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
9cd87eaee3
because rubocop configuration inheritance is
messed up and when using `--ignore-parent-exclusion`,
even though the exit status is 0, the example
still fails because of the configuration issue.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
3e20b2738c
The later RuboCop versions don't work with ruby2.3
so we should lock the version to what works with
ruby2.3 as we haven't dropped the support yet.
And since we're using the older version of rubocop,
also fix `Max` value of `LineLength` to 120, which
is the current standard. Without this, rubocop
will throw the line length offenses.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
46d0a800a2
Previously, we were using the old syntax like:
`task :default => :spec`, but now this commit
uses the new Ruby 1.9 hash syntax.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
b41d0fdb56
since without that, evaluating the gemspec from
outside `File.expand_path( __dir__)` won't work.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
9e5e52a1d9
These offenses appear when you create a gem with
`bundle gem foo` and run `rubocop` over it.
Initially, there were around 45 offenses detected,
but with #3731 and this, the number of offenses
have been reduced to 2.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
fe9dcaa1b4
Using File.open without a block leaves a file reference that causes issues with file operations
commands/binstubs_spec.rb
install/gems/compact_index_spec.rb
install/gems/dependency_api_spec.rb
install/gems/standalone_spec.rb
runtime/executable_spec.rb
4b9a6ca156
Previously, for inclusive ranges, the max would show up as the
end of the range, even though the end was not an integer and would
not be the maximum value. For exclusive ranges, max/minmax would
previously raise a TypeError, even though it is possible to get the
correct maximum.
This change to max/minmax also uncovered a similar error in cover?,
which calls max in certain cases, so adjust the code there so that
cover? still works as expected.
Fixes [Bug #17017]
