Automatically create GitHub releases #753
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I ran the following command:
bundle exec rubocop --auto-gen-config
i.e. * `once` is equivalent to `times(1)` * `twice` is equivalent to `times(2)` * `at_least_once` is equivalent to `at_least(1)` * `at_most_once` is equivalent to `at_most(1)`
Make it clearer that `Expectation#times` can be called with either a number or a range.
…for-cardinality-related-methods Improvements to docs for cardinality related methods
Modifies expectation so that the expected method must be called exactly
three times. While the word "thrice" is somewhat archaic english,
there's no harm in providing it for those that want to use it.
Note that we've also had to re-generate the rubocop TODO list mainly to
cope with the longer length of the `Expectation` class definition using
the following command:
bundle exec rubocop --auto-gen-config
Add `Expectation#thrice`
This version has been EOL since 31 Mar 2017 [1], which is almost 8 years ago. `Mocha::Configuration#stubbing_method_on_nil` and `StubbingNilTest` are now moot, because as of Ruby v2.2 `nil` is frozen. The behaviour tested in the latter is already tested in the more generic `StubbingFrozenObjectTest`. See this commit [2] for details. Closes freerange#628. [1]: https://www.ruby-lang.org/en/downloads/branches/ [2]: freerange@a65ea1e
…-v2.1 Drop support for Ruby v2.1
This brings the gemspec description more into line with that in the README. Note that the gemspec description is used on rubygems.org [1]. Closes freerange#692. [1]: https://rubygems.org/gems/mocha
…ption Improve gemspec description
I was seeing the following warning when I run bundle exec rake lint
locally with Ruby v3.3.6:
~/.asdf/installs/ruby/3.3.6/lib/ruby/gems/3.3.0/gems/rubocop-0.58.2/lib/rubocop.rb:607:
warning: base64 was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.4.0.
You can add base64 to your Gemfile or gemspec to silence this warning.
I imagine newer versions of rubocop might include this as an explicit
dependency or maybe it has become unnecessary, but this fixes the
immediate problem for me.
Closes freerange#703.
The base64 gem does not support Ruby v2.2 and so the previous commit [1] was causing a CI build failure [2]. [1]: freerange@8c49314 [2]: https://app.circleci.com/pipelines/github/freerange/mocha/695/workflows/4c622995-5468-4cfc-a3cf-405fecb39cb0/jobs/10161
In preparation for the Ruby v3.4 release.
I was seeing the following warning when I ran `bundle exec rake lint`
locally with Ruby v3.4.0-rc1:
~/.asdf/installs/ruby/3.4.0-rc1/lib/ruby/gems/3.4.0+1/gems/rubocop-0.58.2/lib/rubocop.rb:607:
warning: ostruct was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0.
You can add ostruct to your Gemfile or gemspec to silence this warning.
Ruby v3.4 was released earlier today [1]. [1]: https://www.ruby-lang.org/en/news/2024/12/25/ruby-3-4-0-released/
…d-matrix Add Ruby v3.4 to CI build matrix
I was seeing the following warnings with Ruby v3.4:
test/method_definer.rb:3: warning: redefining 'object_id' may cause serious problems
test/method_definer.rb:3: warning: redefining '__id__' may cause serious problems
* Assert the string representation of the object instead of just the
pattern.
* Actually check `Object#id` is not called as implied by the test name.
* Ignore the Ruby warning when `Object#object_id` is redefined.
Closes freerange#709.
Fix Ruby v3.4 warnings in ObjectInspectTest
Most of the complication in the default `Gemfile` was to do with rubocop dependencies/compatibility. Extracting this separate `gemfiles/Gemfile.rubocop` simplifies the default `Gemfile` at the cost of making it slightly more complicated to run the `lint` rake task.
This is what I've been using locally for some time without any problems.
* This means we can considerably simplify `gemfiles/Gemfile.rubocop`, because we no longer need any of the workarounds. * I've regenerated the `.rubocop_todo.yml` file. * `Metrics/LineLength` has moved to `Layout/LineLength`. * The equivalent of the `IgnoredPatterns` attribute in `Metrics/LineLength` for `Layout/LineLength` is `AllowedPatterns`. * I have not *yet* opted in to a bunch of *new* cops, so the output is quite verbose. * Similarly, I haven't *yet* opted in to new cops by default by enabling the `AllCops/NewCops` config option. * There is a tip suggesting the `rubocop-rake` extension might be useful which I plan to address separately.
And re-generate to-do list.
I had to change the line numbers of a couple of assertions to match the new line numbers after the blank lines were added.
This means the full list of documentation-related rake tasks is: rake docs # Prepare documentation for publication on GitHub Pages rake docs:clobber # Remove generated documentation rake docs:coverage # Check documentation coverage rake docs:ensure_cname # Ensure custom domain remains in place for docs on GitHub Pages rake docs:ensure_js # Ensure custom JavaScript files remain in place for docs on GitHub Pages rake docs:generate # Generate documentation I've disabled the `Metrics/BlockLength` cop in the whole `Rakefile`, because the cop seems less important in the context of a DSL like rake.
…erage-check Add documentation coverage check
fix: cop Lint/LiteralAsCondition offence
I was seeing the following warning:
warning: rdoc was loaded from the standard library,
but will no longer be part of the default gems
starting from Ruby 3.5.0.
Fix rdoc-related warning when running doc rake task
ruby 2.x emitted warning: instance variable @logger not initialized
JRuby emits the warning: ObjectMethods#method accesses caller method's state and should not be aliased. see ruby/ostruct#40 for the reasons
…arnings Builds fail fast on any ruby warnings
Rename respond_to? to stubba_respond_to? to better reflect its purpose as part of a mocha contract. `Mockery#on_stubbing` now uses `stubba_respond_to?` instead of the generic `respond_to?` to check if an object responds to a method before stubbing it. Added `ObjectMethods#stubba_respond_to?` to provide a consistent interface for checking if an object responds to a method. The new `#stubba_respond_to?` methods: * are like `respond_to?` and unlike `respond_to_missing?`, because they don't let method definitions in `ObjectMethods` or `AnyInstance` affect its outcome. * make the internal/service provider contract implemented by `AnyInstance` & `ObjectMethods` explicit and independent of Ruby core/standard API.
As stated in commits e423977, 33e373c, fddebc3: > Ideally I would've configured the extra `AllowedMethods` to only apply > to the tests, but I couldn't find a simple way to do that with the > rubocop configuration. It might be worth extracting a separate rubocop > configuration for the tests. Here we do just that.
Rename `respond_to?` -> `stubba_respond_to?`
stubbee is the thing that's stubbed - more specifically, the object on which .stubs or .mocks is called. Therefore, it's also the object that holds a reference to mocha. That's why it was called mock_owner earlier. stubba_object is the object through which we get hold of the stubba_class on which stubbed methods reside. In case of AnyInstance, that class is the stubba_object itself, while in case of Instance, it's the singleton class of the stubba_object.
Rename `#stubbee` -> `#stubba_object` and `#mock_owner` -> `#stubbee`
Also, an explicit message before exiting is unnecessary in our context since any warnings will be right there
The earlier export was probably having no effect. The circleci 'Set an environment variable' doc [1] states: Since every run step is a new shell, environment variables are not shared across steps. If you need an environment variable to be accessible in more than one step, export the value using BASH_ENV. - [1]: https://circleci.com/docs/set-environment-variable/#set-an-environment-variable-in-a-step
…rning Fix enable-frozen-string-literal and clean up step display in CircleCI UI
Introduces a new GitHub Actions workflow that automates the creation of GitHub releases. The workflow is triggered on push events to tags that start with 'v', and it extracts release notes from the RELEASE.md file based on the tag version. The extracted notes are then used as the body of the created release.
Member
|
@nitishr This looks good to me - thank you!
Agreed.
I think I'd probably move the CI build to GitHub Actions instead unless you can think of a good reason not to.
Thanks for testing it. I'd quite like to retrospectively create releases for all the existing release tags, so perhaps I can use the same (or a similar) script to do that when I have time and use that as a bit of a test...? |
floehopper
force-pushed
the
main
branch
2 times, most recently
from
ebb1c3e to
31e433a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #749.
Introduces a new GitHub Actions workflow that automates the creation of GitHub releases. The workflow is triggered on push events to tags that start with 'v', and it extracts release notes from the RELEASE.md file based on the tag version. The extracted notes are then used as the body of the created release.
Future considerations:
Testing
Verified the outcome of this workflow by updating
RELEASE.mdand pushing a tag to a local branch. The created release contains the extracted notes for just that release.