This is just a suggestion, but since recent versions of Ruby have shipped with a `binding.irb` that provides almost all of the features that `pry` pioneered, it may be time to remove this suggestion in the name of simplicity and not confusing newer developers who aren't familiar with what to use.
Currently, the instructions and placeholder contradict each other.
The commit that introduced this placeholder (42bc4715d920e836c8499883d)
makes it clear that the placeholder should be replaced AFTER publishing
(i.e. once the author successfully claims the gem name on Rubygems), so
the placeholder should match.
23e2dea828
...with dashed gem name
In "bundle gem" command with dashed name gem (e.g. foo-bar) generates
`test/test_foo/bar.rb`, but this file contains undefined class `TestFoo`
and moreover, does not include in "bundle exec rake test" target.
Therefore, intentially the first test after gem created is fail, but in
case of gem name contains dash character is not.
The change doings...
(when "bundle gem foo-bar" called)
* create `test/test_foo_bar.rb`
* define `TestFooBar` class in `test/test_foo_bar.rb`
5d9a69fc0f
This change avoids a YAML Float-to-String conversion, which turns a 3.0 into a "3". That can make names of builds less clear.
In order to use this new capability, I added a "name" descriptor to the matrix-created Job.
6221241ad4
I am not sure why this flag was turned off (it wasn't explained in my commit message in 0365dc852767ae589376a7aad1fb129738e408b0 or in my PR in #4411).
Whatever the reason, without `default_ignores` turned on, most default CI configurations will immediately fail, as they most likely vendor and cache their dependencies under `vendor`, which will cause standard to run against all the vendored gems and (most likely) fail. I think we should remove this before this feature is released.
677f74be48
Even if it only has one entry at the moment, it makes it easier to add
new entries by doing it this way.
46232fe265
Co-authored-by: NeimadTL <damientalbot26@gmail.com>
Otherwise CI will run once for every pull request update and once for
every push.
The disavantage is that people working on a non default branch without
creating pull requests won't get CI run at all.
I think the advantages are greater than the disadvantages, it's also my
personal workflow, and it's something desired enough so that someone
opened an issue about it.
So let's do it!
924d916a73
Co-authored-by: NeimadTL <damientalbot26@gmail.com>
To mimic built-in rubygems behaviour, only thing that should be
approximated is the lockfile version. Other alternatives like
`BUNDLER_VERSION` should be respected exactly.
dbd667d4bc
In an executable script, the shebang line should be the first line (the
file needs to start with the bytes 0x23 0x21). Putting a comment above
it will break the script.
(Regression test included per @deivid-rodriguez)
962e669feb
As splitting by NUL means to allow the file names to contain
newlines, path names should match at beginning-of-string instead
of beginning-of-line.
8a81183236
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
