svenfuchs / gem-release Goto Github PK
View Code? Open in Web Editor NEWRelease your ruby gems with ease.
License: MIT License
Release your ruby gems with ease.
License: MIT License
When running gem release
a success message gets printed even if the release didn't succeed (I disconnected from internet for testing purposes).
Check this line:
Feature Suggestion: --date to bump the datestamp in the gemspec when bumping
This would really complete the transition from Jeweler for me. I find I forget to bump the date alot. Apparently rubygems.org uses the date from the gemspec, and not the date you push a gem. I have a bunch of consecutive releases all appearing as on the same day on rubygems, which makes it look like my code was buggy, when really I just forgot to manually bump the date.
As discussed in #15, we should add a prompt to gem release
(and gem bump --release
) for confirmation before pushing both public and private gems.
For instance, Release version 1.0.1 of public_gem to rubygems.org? (y / n)
or Release version 1.0.0 of private_gem to http://rubygems.example.com? (y / n)
. Skip this prompt with the --quiet
/ -q
option.
After installing gem-release version 2.0.1, I found that all my gem commands print error message like this:
Error loading RubyGems plugin "~/.rvm/gems/ruby-2.2.4/gems/gem-release-2.0.1/lib/rubygems_plugin.rb": ~/.rvm/gems/ruby-2.2.4/gems/gem-release-2.0.1/lib/gem/release/cmds/release.rb:12: syntax error, unexpected tIDENTIFIER, expecting keyword_do or '{' or '('
...e given gemspec(s), pushes them to rubygems.org
Then I check the source code of the gem-release, seems like multi-line string syntax like <<~str
is not supported on ruby 2.2.4 or lower, syntax like <<-str
works just fine.
I think it will be better if you can specific the ruby version gem-release supports in the gemspec or change all the <<~str
to <<-str.split("\n").map(&:lstrip).join("\n")
? Now I change my local gem-release code to make it work~
THX
$ gem bump -v patch --tag --push --pretend
Bumping travis-conditions from version 1.0.0-dev.2 to 1.0.0
Staging lib/travis/conditions/version.rb
$ git add lib/travis/conditions/version.rb
Creating commit
$ git commit -m "Bump travis-conditions to 1.0.0"
Pushing to the origin git repository
$ git push origin
Tagging travis-conditions as version 1.0.0.pre.dev.2
Creating git tag v1.0.0.pre.dev.2
$ git tag -am "tag v1.0.0.pre.dev.2" v1.0.0.pre.dev.2
Pushing tags to the origin git repository
$ git push --tags origin
All is good, thanks my friend.
Need to add rubysl-test-unit
as a dependency to make rubinius happy.
Hi, I'm trying to use the gem like this: gem bump --tag --skip-ci --push --version patch
my current version is 0.0.1 and I'm bumping to 0.1.0
I'm expecting the tag to be set to 'v0.1.0' but instead I'm getting this output (and the tag created is the same):
bump my-gem 0.0.1 0.1.0
version lib/my-gem/version.rb 0.0.1 0.1.0
git_add lib/my-gem/version.rb
git_commit "Bump my-gem to 0.1.0 [skip ci]"
[master 128a501] Bump my-gem to 0.1.0 [skip ci]
1 file changed, 1 insertion(+), 1 deletion(-)
git_push origin
tag my-gem 0.0.1
git_tag v0.0.1 v0.0.1
git_push origin
It would be nice if gem-release
would offer an option to also create an according new github release when using the gem release
command (e.g. via gem release --github
).
Github offers a simple API for this purpose. You can automatically create a new Github release using a simple POST, see https://developer.github.com/v3/repos/releases/#create-a-release.
$ gem bump --help
Usage: gem [options]
Options:
-v, --version VERSION Target version: next [major|minor|patch|pre|release] or a given version number [x.x.x] (not set by default)
-c, --[no-]commit Perform a commit after incrementing gem version (defaults to true)
-p, --[no-]push Push to the git destination (defaults to false)
-d, --destination DESTINATION destination git repository (defaults to origin)
-t, --[no-]tag Create a git tag and push it to the git destination (defaults to false)
-r, --[no-]release Build gem from a gemspec and push to rubygems.org (defaults to false)
-k, --key KEY When releasing: use the given API key from ~/.gem/credentials (not set by default)
--host HOST When releasing: push to a gemcutter-compatible host other than rubygems.org (not set by default)
Common Options:
-h, --help Get help on this command
-V, --[no-]verbose Set the verbose level of output
-q, --quiet Silence commands
--config-file FILE Use this config file instead of default
--backtrace Show stack backtrace on errors
--debug Turn on Ruby debugging
Summary:
Bump the gem version
It sometimes fails, esp. since it's not handling encodings atm, so it would be cool if it wouldn't create a tag before trying to build the gem.
I have a RubyGem with another RubyGem in-repo (directly, not a submodule). The file structure looks something like:
The gemspecs look normal, i.e. like they would if they were in separate repos. In the two Gemfiles, after the gemspec
directive, I'm using the :path
option to point to the relative directories for development. So something like:
# sinja/Gemfile
gemspec
gem 'sinja-sequel', :require=>false, :path=>'extensions/sequel'
# sinja/sinja.gemspec
spec.add_development_dependency 'sinja-sequel', '~> 0.1'
# sinja/extensions/sequel/Gemfile
gemspec
gem 'sinja', :require=>false, :path=>'../..'
# sinja/extensions/sequel/sinja-sequel.gemspec
spec.add_dependency 'sinja', '>= 1.2.0.pre2', '< 2'
Here's the scoop:
bundle install|update|exec
works fine in both gemspec directoriesgem build|push
works fine in both gemspec directoriesgem bump
finds sinja/extensions/sequel/lib/sinja/sequel/version.rb
first and uses it as the base version for both gems, updating both version.rb
files to the new version (PROBLEM 1)gem release
works fine in sinja/extensions/sequel/
gem release
in sinja/
finds sinja/extensions/sequel/sinja-sequel.gemspec
first and tries to re-release it (PROBLEM 2)gem release sinja.gemspec
emits ERROR: Gemspec file not found: sinja.gemspec
(PROBLEM 3)PROBLEM 1: How can I restrict gem bump
to only work on one or the other version.rb
file at a time?
PROBLEM 2: Why doesn't gem release
in the top-level directory find the top-level gemspec?
PROBLEM 3: What in the blazes is going on here?
/tmp $ bundle gem foo-bar
create foo-bar/Gemfile
create foo-bar/Rakefile
create foo-bar/.gitignore
create foo-bar/foo-bar.gemspec
create foo-bar/lib/foo-bar.rb
create foo-bar/lib/foo-bar/version.rb
Initializating git repo in /private/tmp/foo-bar
/tmp $ cd foo-bar/
/tmp/foo-bar $ gem bump --version patch
Ignoring foo-bar. Version file /private/tmp/foo-bar/lib/foo_bar/version.rb not found
No version files could be found, so no actions were performed.
We've been writing some gems that need to have "*_rb" at the end for the gem name
Ex.
# gem name is task_rb
lib/task/version.rb
It would be great if gem bump
worked on this as well
Gem is published. Server still sends back an error mesage.
This is for a very active gem, https://github.com/shakacode/react_on_rails
Using this repo: https://github.com/svenfuchs/gem-release
and this script:
https://github.com/shakacode/react_on_rails/blob/master/rakelib/release.rake#L64
+ [email protected]
No distRepo provided, done.
cd /Users/justin/shakacode/react-on-rails/react_on_rails && gem release
WARNING: open-ended dependency on connection_pool (>= 0) is not recommended
if connection_pool is semantically versioned, use:
add_runtime_dependency 'connection_pool', '~> 0'
WARNING: open-ended dependency on rails (>= 3.2) is not recommended
if rails is semantically versioned, use:
add_runtime_dependency 'rails', '~> 3.2'
WARNING: open-ended dependency on addressable (>= 0) is not recommended
if addressable is semantically versioned, use:
add_runtime_dependency 'addressable', '~> 0'
WARNING: open-ended dependency on rspec (>= 0, development) is not recommended
if rspec is semantically versioned, use:
add_development_dependency 'rspec', '~> 0'
WARNING: open-ended dependency on coveralls (>= 0, development) is not recommended
if coveralls is semantically versioned, use:
add_development_dependency 'coveralls', '~> 0'
WARNING: open-ended dependency on generator_spec (>= 0, development) is not recommended
if generator_spec is semantically versioned, use:
add_development_dependency 'generator_spec', '~> 0'
WARNING: open-ended dependency on pry (>= 0, development) is not recommended
if pry is semantically versioned, use:
add_development_dependency 'pry', '~> 0'
WARNING: open-ended dependency on pry-byebug (>= 0, development) is not recommended
if pry-byebug is semantically versioned, use:
add_development_dependency 'pry-byebug', '~> 0'
WARNING: open-ended dependency on pry-stack_explorer (>= 0, development) is not recommended
if pry-stack_explorer is semantically versioned, use:
add_development_dependency 'pry-stack_explorer', '~> 0'
WARNING: open-ended dependency on pry-doc (>= 0, development) is not recommended
if pry-doc is semantically versioned, use:
add_development_dependency 'pry-doc', '~> 0'
WARNING: open-ended dependency on pry-state (>= 0, development) is not recommended
if pry-state is semantically versioned, use:
add_development_dependency 'pry-state', '~> 0'
WARNING: open-ended dependency on pry-toys (>= 0, development) is not recommended
if pry-toys is semantically versioned, use:
add_development_dependency 'pry-toys', '~> 0'
WARNING: open-ended dependency on pry-rescue (>= 0, development) is not recommended
if pry-rescue is semantically versioned, use:
add_development_dependency 'pry-rescue', '~> 0'
WARNING: open-ended dependency on binding_of_caller (>= 0, development) is not recommended
if binding_of_caller is semantically versioned, use:
add_development_dependency 'binding_of_caller', '~> 0'
WARNING: open-ended dependency on awesome_print (>= 0, development) is not recommended
if awesome_print is semantically versioned, use:
add_development_dependency 'awesome_print', '~> 0'
WARNING: open-ended dependency on gem-release (>= 0, development) is not recommended
if gem-release is semantically versioned, use:
add_development_dependency 'gem-release', '~> 0'
WARNING: See http://guides.rubygems.org/specification-reference/ for help
Successfully built RubyGem
Name: react_on_rails
Version: 6.8.2
File: react_on_rails-6.8.2.gem
Pushing gem to https://rubygems.org...
Successfully registered gem: react_on_rails (6.8.2)
Deleting left over gem file react_on_rails-6.8.2.gem
WARNING: open-ended dependency on connection_pool (>= 0) is not recommended
if connection_pool is semantically versioned, use:
add_runtime_dependency 'connection_pool', '~> 0'
WARNING: open-ended dependency on rails (>= 3.2) is not recommended
if rails is semantically versioned, use:
add_runtime_dependency 'rails', '~> 3.2'
WARNING: open-ended dependency on addressable (>= 0) is not recommended
if addressable is semantically versioned, use:
add_runtime_dependency 'addressable', '~> 0'
WARNING: open-ended dependency on rspec (>= 0, development) is not recommended
if rspec is semantically versioned, use:
add_development_dependency 'rspec', '~> 0'
WARNING: open-ended dependency on coveralls (>= 0, development) is not recommended
if coveralls is semantically versioned, use:
add_development_dependency 'coveralls', '~> 0'
WARNING: open-ended dependency on generator_spec (>= 0, development) is not recommended
if generator_spec is semantically versioned, use:
add_development_dependency 'generator_spec', '~> 0'
WARNING: open-ended dependency on pry (>= 0, development) is not recommended
if pry is semantically versioned, use:
add_development_dependency 'pry', '~> 0'
WARNING: open-ended dependency on pry-byebug (>= 0, development) is not recommended
if pry-byebug is semantically versioned, use:
add_development_dependency 'pry-byebug', '~> 0'
WARNING: open-ended dependency on pry-stack_explorer (>= 0, development) is not recommended
if pry-stack_explorer is semantically versioned, use:
add_development_dependency 'pry-stack_explorer', '~> 0'
WARNING: open-ended dependency on pry-doc (>= 0, development) is not recommended
if pry-doc is semantically versioned, use:
add_development_dependency 'pry-doc', '~> 0'
WARNING: open-ended dependency on pry-state (>= 0, development) is not recommended
if pry-state is semantically versioned, use:
add_development_dependency 'pry-state', '~> 0'
WARNING: open-ended dependency on pry-toys (>= 0, development) is not recommended
if pry-toys is semantically versioned, use:
add_development_dependency 'pry-toys', '~> 0'
WARNING: open-ended dependency on pry-rescue (>= 0, development) is not recommended
if pry-rescue is semantically versioned, use:
add_development_dependency 'pry-rescue', '~> 0'
WARNING: open-ended dependency on binding_of_caller (>= 0, development) is not recommended
if binding_of_caller is semantically versioned, use:
add_development_dependency 'binding_of_caller', '~> 0'
WARNING: open-ended dependency on awesome_print (>= 0, development) is not recommended
if awesome_print is semantically versioned, use:
add_development_dependency 'awesome_print', '~> 0'
WARNING: open-ended dependency on gem-release (>= 0, development) is not recommended
if gem-release is semantically versioned, use:
add_development_dependency 'gem-release', '~> 0'
WARNING: See http://guides.rubygems.org/specification-reference/ for help
Successfully built RubyGem
Name: react_on_rails
Version: 6.8.2
File: react_on_rails-6.8.2.gem
Pushing gem to https://rubygems.org...
Repushing of gem versions is not allowed.
Please use `gem yank` to remove bad gem releases.
rake aborted!
Command failed with status (1): [cd /Users/justin/shakacode/react-on-rails/...]
/Users/justin/shakacode/react-on-rails/react_on_rails/rakelib/task_helpers.rb:20:in `block in sh_in_dir'
/Users/justin/shakacode/react-on-rails/react_on_rails/rakelib/task_helpers.rb:20:in `each'
/Users/justin/shakacode/react-on-rails/react_on_rails/rakelib/task_helpers.rb:20:in `sh_in_dir'
/Users/justin/shakacode/react-on-rails/react_on_rails/rakelib/release.rake:64:in `block in <top (required)>'
/Users/justin/.rvm/gems/ruby-2.3.1@react_on_rails/gems/rake-12.0.0/exe/rake:27:in `<top (required)>'
Tasks: TOP => release
(See full trace by running task with --trace)
See #1589 and Issue on RubyGems.
When combining bump with the tag or release options, the tag and release commands attempt to work with the prior version number. Oddly, the tests cover these scenarios and pass without a problem, so there must be an issue within the tests as well.
I suspect that the gemspec file isn't truly being reloaded when invoking release and/or tag, but I haven't yet found why. I'll continue to look into this, unless you see something obvious, @svenfuchs.
By the way, issuing a "gem bump" followed by "gem release" or "gem tag" works just as expected.
gem bootstrap -f
should add
s.files = Dir.glob("{lib//,[A-Z]}")
but it actually adds
s.files = git ls-files app lib
.split("\n")
(using 0.2.1)
Small issue with bumping existing gems.
Steps to reproduce:
Create a gem with version number 2.0
Bump with gem bump -v patch
Error message:
ERROR: While executing gem ... (NoMethodError)
undefined method `compact' for nil:NilClass
It took me a while to figure out where the error popped up.
The problem is that the target is not being set correctly in Gem::Release::Version::Number
Just add those for since 0.7.0
It would be nice if one could integrate this gem with Rake Tasks that incorporates options.
My current workaround:
desc 'Bumps and pushes new minor version.'
task :bump_minor do
puts 'Bumping minor.'
cmd = 'gem bump --version minor --tag --push'
raise 'Error bumping minor version!' unless system(cmd)
end
desc 'Bumps and pushes new major version.'
task :bump_major do
puts 'Bumping major.'
cmd = 'gem bump --version major --tag --push'
raise 'Error bumping major version!' unless system(cmd)
end
desc 'Bumps and pushes new patch version.'
task :bump_patch do
puts 'Bumping patch.'
cmd = 'gem bump --version patch --tag --push'
raise 'Error bumping patch version!' unless system(cmd)
end
A bit of unexpected behaviour. Perhaps it should be documented in the README or the help output, perhaps?
I expect that if I pass a name to gem bootstrap
, it would use that name, create the directory and then do it's jazz. Instead it uses the current directory for the name. Whoops!
I've been using bundler for bootstrapping my gems (bundle gem my_gem
), but it hasn't been quite enough control for me. I feel like gem-release solves a lot of the issues I have with bundler in particular with give me the gem bump
command which is awesome.
One of the things I really love about bundler is that is makes gems private by default. Most of the work I do is propietary, so I don't want to accidentally push a new gem to RubyGems. It would be great if gem-release had an option for this when bootstrapping a project.
This is how bundler solves the RubyGems push issue: https://github.com/bundler/bundler/blob/master/lib/bundler/templates/newgem/newgem.gemspec.tt#L19
Neat gem; I like it a lot.
Is there a way to get the current version without having to grep
or sed
lib/my_gem/version.rb? I'd like to have a task in a Rakefile to create a git branch with the name of the version, similar to your gem tag
command, but I'm having trouble figuring out the right incantations. Alternatively, being able to get the "bumped" new version as just a plain text-string on STDOUT would let me mess with it on my own, like a stripped-down --pretend
.
These are probably more enhancement requests than Issues...
Thanks for the good work! :-)
I am trying to provide a custom message for bumping version like
gem bump patch -m '<messge>'
It throws below error
undefined method `%' for true:TrueClass
i have some gems that are "managed" by repo and i would prefer to just push the tags with repo
While attempting to extend the bump
command, I encountered a nasty problem for gem-release in Ruby 1.9.x that doesn't occur in 1.8.7, REE, or jRuby. When bumping and releasing or tagging a gem at the same time (e.g gem bump -t -r
), the old version number, instead of the new bumped version number, gets tagged and released. Luckily, this tends to fail, since duplicate versions can't be tagged in git or pushed up to rubygems.org.
I've created a new bump_tag_and_release branch that now illustrates the problem with a test.
Because of this bug, I've removed these options from bump
and pushed out a new version of gem-release: 0.2.0.
The problem seems to be that the version loaded by Gem::Specification.load() is not getting reloaded by TagCommand and ReleaseCommand for 1.9+.
One question is whether we really want to continue to support the release and tag options for bump
. This is not in my own workflow, which tends to be a separate gem bump -p
followed by a gem release -t
. Upon adding key
and host
options to bump
, it was beginning to look like an alpabet soup of options - perhaps too many to use reliably.
Does anyone feel strongly about keeping release
and tag
in bump
?
@svenfuchs - thoughts? by the way, the only reason this project is failing in travis is because of the new branch; master is fine.
Hi,
it would be nice to have the --quiet flag for all subcommands. I currently use gem bump in a filter script for git-flow and it is a real pain to catch all output by gem bump to make sure that the filter just returns the version to use for the release.
it went from v0.1.0.pre3
directly to v0.1.1
https://github.com/svenfuchs/simple_states/tags
:)
(using gem-release 0.3.1
)
Hi, this is probably not problem in gem release
, opening anyway as maybe it will help others troubleshooting.
I've tried enabling multi-factor authentication in rubygems.org at "UI and API".
This should make gem push
prompt for an OTP code:
https://guides.rubygems.org/using-mfa-in-command-line/
But I didn't use gem push
directly, I used gem release
which it seems failed, without prompting me for an OTP code. (Sorry, didn't save the output, laptop lost power since).
Is there any known limitation? Are executed commands connected to stdin?
Alternatively, could add an --otp
flag to be passed on to gem push
, requiring no interaction.
Hmm, possibly my gem
CLI was old? I got via rbenv install 2.5.6
; gem --version
says 2.7.6.2, and it doesn't support --otp
, so I guess doesn't know how to prompt either.
Building ruby 2.6.4 gave me gem
3.0.3 which does support --otp
so I guess could Just Work? I'll confirm next time I make a release...
P.S. another workaround: gem release
worked when I set my account MFA to "UI only" level. This is weaker but better than nothing.
[additional search keywords: 2FA, OTP]
I don't know how this happened, but gem release 0.6.0 has started pushing the wrong versions of my gems to rubygems.org. Here is one example
∴ gem bump --tag --release
Bumping flag_shih_tzu from 0.3.9 to version 0.3.10
Creating commit
[master f673691] Bump to 0.3.10
1 file changed, 1 insertion(+), 1 deletion(-)
Pushing to the origin git repository
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 501 bytes | 0 bytes/s, done.
Total 5 (delta 1), reused 0 (delta 0)
To https://github.com/pboling/flag_shih_tzu.git
4f60d20..f673691 master -> master
Successfully built RubyGem
Name: flag_shih_tzu
Version: 0.3.9
File: flag_shih_tzu-0.3.9.gem
Pushing gem to https://rubygems.org...
Repushing of gem versions is not allowed.
Please use `gem yank` to remove bad gem releases.
Running straight gem release
works:
∴ gem release
Successfully built RubyGem
Name: flag_shih_tzu
Version: 0.3.10
File: flag_shih_tzu-0.3.10.gem
Pushing gem to https://rubygems.org...
Successfully registered gem: flag_shih_tzu (0.3.10)
Deleting left over gem file flag_shih_tzu-0.3.10.gem
All is good, thanks my friend.
My project dir is inside "/Users/seanmackesey/Google Drive/code/lib/ruby"
. When I run gem bump
, I get
fatal: '/Users/seanmackesey/Google' is outside repository
The taskbump
could not be completed. Subsequent tasks will not be attempted.
Looks like an issue with that space.
Unfortunately, rubygems requires a .
separator instead of a -
for pre-release gems. Would it be possible to update gem-release to comply with that constraint?
Ex. "0.169.0"
should gem bump -v pre
to "0.170.0.pre.1"
instead of "0.170.0-pre.1"
See rubygems/rubygems#592 (comment) and the offending line that causes all the issues: https://github.com/rubygems/rubygems/blob/064cfaf7f5357c16a4fae04d53587fcf69b6df3f/lib/rubygems/version.rb#L219
I was on a branch locally when i ran gem bump --tag --release --version minor
and it performed all the actions while still on that branch instead of on the master branch. I'm sure it's my fault, but it was kind of a foot gun and I thought i'd mention it since there may be something that could be done, like having an option in the config that allows you to specify which branch to perform the actions on.
Currently, gem-release performs git push --tags
when tagging a release. If there are any commits outstanding, as there often are when bumping a version, it's necessary to perform a separate git push
to get the working branch sync'd with origin.
Should we combine these commands in TagCommand ?
def push
say "Pushing to origin git repository" unless quiet?
`git push origin`
say "Pushing --tags to origin git repository" unless quiet?
`git push --tags origin`
end
I've always been confused as to why git forces these steps to be separate, so perhaps I'm missing something. Either way, it would be good to understand the rationale.
This used to work.
I'd love some help to debug this.
Script with pointer to failing line: https://github.com/shakacode/react_on_rails/blob/master/rakelib/release.rake#L51
rake release[3.0.3,false,false]
rm -rf /Users/justin/shakacode/react_on_rails/gen-examples/examples
cd /Users/justin/shakacode/react_on_rails && gem bump --no-commit --version 3.0.3
ERROR: While executing gem ... (Gem::CommandLineError)
Unknown command bump
rake aborted!
Command failed with status (1): [cd /Users/justin/shakacode/react_on_rails ...]
/Users/justin/shakacode/react_on_rails/rakelib/task_helpers.rb:20:in `block in sh_in_dir'
/Users/justin/shakacode/react_on_rails/rakelib/task_helpers.rb:20:in `each'
/Users/justin/shakacode/react_on_rails/rakelib/task_helpers.rb:20:in `sh_in_dir'
/Users/justin/shakacode/react_on_rails/rakelib/release.rake:51:in `block in <top (required)>'
/Users/justin/.rvm/gems/ruby-2.2.4@react_on_rails/bin/ruby_executable_hooks:15:in `eval'
/Users/justin/.rvm/gems/ruby-2.2.4@react_on_rails/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => release
(See full trace by running task with --trace)
Since bootstrapping a gem also inits git, I think we should create a default .gitignore
file too.
It could contain the following:
*.gem
Gemfile.lock
Any other candidates to exclude?
Also, should Gemfile.lock be removed from gem-release
itself? In general, Gemfile.lock files should be excluded from git for gems, but not apps, although I'm not sure how I feel about it here.
@svenfuchs - your thoughts please :)
When a .gemrelease file is created with, for example, a host for release:
---
release:
host: 'http://foo.bar'
The file is picked up when issueing gem release
but the file is ignored when combining the release command with another command gem bump --version 1.1.3 --release
Without the --scaffold
option, gem bootstrap
is pretty much redundant with gem gemspec
. Why not make --scaffold
the default?
I think it's much easier to remember and use this:
gem bootstrap new_gem
than this:
gem bootstrap new_gem --scaffold
And I imagine this is one of the most common use cases for gem-release
.
Hey, I assume this more an error on my part, but I see the following output while running gem release
Enter your RubyGems.org credentials.
Don't have an account yet? Create one at http://rubygems.org/sign_up
Email:
Password:
Pushing gem to https://rubygems.org...
HTTP Basic: Access denied.
I have setup my credentials for rubygems in ~/.gem/credentials and am using the correct values when running gem release
.
Any ideas?
Cheers!
I have a dir bin
with an executable file in it. It would be nice if gem bootstrap
and gem gemspec
would add this to the gemspec
I guess that's
s.executables << 'foo'
when bin
contains the executable file foo
?
As discussed in #15, gem-release should allow for an entirely optional yaml configuration file named .gemrelease
. This file could mirror the command / options available for gem-release. For instance:
release:
host: http://rubygems.example.com
key: keyname
It could also be used to disable commands:
release: disabled
This would be useful for private gems that are built from source by bundler and never pushed to a host (e.g. gem 'private_gem', :git => '[email protected]:example/private_gem.git'
).
Hello.
First of all, thanks for making this gem. I was very glad when I have found it. :)
I have a question.
I want to use this gem and everything is fine. But in addition to existing functionality I also would to bump version in my changelog file.
E.g.
before
--- CHANGELOG.md 2019-10-11 13:00:11.095262564 +0300
+++ CHANGELOG.md 2019-10-11 13:00:12.455265870 +0300
@@ -1 +1,3 @@
## Unreleased
+
+## 0.3.1 - 2019-09-09
Bugfixes:
- fix 1 ...
- fix 2
## 0.3.0 - 2019-09-01
Is there any way to do this? May be some way to hook into bump
command somewhere between actual changing of version.rb
file and making a commit.
For now I use a workaround... I write simple script which invokes gem bump --no-commit --branch
, then I make changes in CHANGELOG.md
and then I invoke git add
and git push
myself.
I will be glad to hear your thoughts.
I've been using this gem for a number of projects and really appreciate the work that has gone into it. ❤️
When generating a release, I wonder if it would be possible to also update the changelog listed in the gemspec since the last tag. Maybe in an interactive fashion, allowing the user to select, comment, and link to the commits?
I'd be willing to put some effort into this if the idea aligns with the project.
running gem build
followed by gem push --key foo --host http://foo.host/private
works.
However with a .gemrelease
release:
key: foo
host: http://foo.host/private
Running gem release
fails, with a 401 from my gem server:
...
Pushing gem to http://foo.host/private...
Authorization key is invalid
...
Tasks: TOP => release => release:rubygem_push
Are host
and key
not designed to work in this manner? Documentation leads me to believe they are.
With VERSION being 0.1.0.pre2
I got:
simple_states [master] $ gem bump
ERROR: While executing gem ... (NoMethodError)
undefined method `sub' for nil:NilClass
DB:~/ruby $ bundle gem test
create test/Gemfile
create test/Rakefile
create test/.gitignore
create test/test.gemspec
create test/lib/test.rb
create test/lib/test/version.rb
Initializating git repo in /Users/denis/ruby/test
DB:~/ruby $ cd test
DB:~/ruby/test $ ls
Gemfile Rakefile lib test.gemspec
DB:~/ruby/test $ gem bump
Bumping from 0.0.1 to version 0.0.2
Creating commit
/Users/denis/ruby/test/lib/test/version.rb:2: warning: already initialized constant VERSION
This is using gem 1.8.5, gem-release 0.0.16, bundler 1.0.15 and ruby 1.9.2p180. I looked around in the code.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.