building-and-testing-ruby.md - remove wildcard, version, clarify x.0 #13418
Conversation
|
Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines. |
|
Thanks for submitting a PR to the GitHub Docs project! In order to review and merge PRs most efficiently, we require that all PRs grant maintainer edit access before we review them. For information on how to do this, see the documentation. |
Automatically generated comment ℹ️This comment is automatically generated and will be overwritten every time changes are committed to this branch. The table contains an overview of files in the Content directory changesYou may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.
|
| @@ -87,13 +87,13 @@ Alternatively, you can check a `.ruby-version` file into the root of your repos | |||
|
|
|||
| ## Testing with multiple versions of Ruby | |||
|
|
|||
| You can add a matrix strategy to run your workflow with more than one version of Ruby. For example, you can test your code against the latest patch releases of versions 2.7, 2.6, and 2.5. The 'x' is a wildcard character that matches the latest patch release available for a version. | |||
| You can add a matrix strategy to run your workflow with more than one version of Ruby. For example, you can test your code against the latest patch releases of versions 3.0, 2.7, and 2.6. YAML parsers will truncate trailing zeros from numeric values, and often convert floats to integers. So, an unquoted 3.0 is converted to an integer, so it will match any minor version, as in 3.0.3, 3.1.0, etc. Likewise, 2.10 needs to be quoted, otherwise it will be interpreted as 2.1. | |||
There was a problem hiding this comment.
| You can add a matrix strategy to run your workflow with more than one version of Ruby. For example, you can test your code against the latest patch releases of versions 3.0, 2.7, and 2.6. YAML parsers will truncate trailing zeros from numeric values, and often convert floats to integers. So, an unquoted 3.0 is converted to an integer, so it will match any minor version, as in 3.0.3, 3.1.0, etc. Likewise, 2.10 needs to be quoted, otherwise it will be interpreted as 2.1. | |
| You can add a matrix strategy to run your workflow with more than one version of Ruby. For example, you can test your code against the latest patch releases of versions 3.0, 2.7, and 2.6. The YAML parser used by GitHub Actions will truncate trailing zeros from numeric values, and often convert floats to integers. So, an unquoted 3.0 is converted to an integer, so it will match any minor version, as in 3.0.3, 3.1.0, etc. Likewise, 2.10 needs to be quoted, otherwise it will be interpreted as 2.1. |
It is good that we document this gotcha, but it sounds like it is a bug that should be addressed: actions/runner#849 (comment)
There was a problem hiding this comment.
IDK. The text I wrote was meant to not be specific, as most coders would prefer [3.0, 2.7, 2.6] to ['3.0', '2.7', '2.6']. Each item is really an array match to a version string (split into an array), which isn't a number (ie, major.minor.patch, or 3.0.1, worse with alphas, betas, rc's, etc). Hence, I wanted to make readers aware of it without implying a yaml parser is working incorrectly. Not the best explanation, but...
off-topic: For people who don't code Ruby, it's a non-typed language, but 1/3 = 0 and 1/3.0 = 0.333...
Hence, Ruby considers 3 to be an int, and 3.0 to be a float. So, Ruby's default yaml parser considers 3 to be an int, and 3.0 to be a float.
There was a problem hiding this comment.
Coders may prefer [3.0, 2.7, 2.6] for simplicity, but those aren't numbers, they're strings and they should be quoted. Otherwise you will run into exactly the problem that you describe where 2.10 needs to be quoted to disambiguate from 2.1. I would illustrate the happy path in the doc and then explain why you've quoted all the version numbers instead of trying to tell people when they need to quote.
There was a problem hiding this comment.
That makes sense @MSP-Greg. I think that it's safe to say that mine is an unpopular opinion, so I'd like to give some time to give others a chance to provide feedback, but I think that we should encourage users to quote version numbers and ensure that the starter workflows follow our guidance here.
There was a problem hiding this comment.
Coders may prefer [3.0, 2.7, 2.6] for simplicity, but those aren't numbers, they're strings and they should be quoted.
I agree with this. The semantic version isn't actually a number, it just works in some cases to treat it as such. Although people often leave out the quotes, we try to craft examples in the docs that illustrate best practices and that will work if users copy-paste-edit without being aware of nuances like this.
|
@dentarg |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Thank you for this improvement! I think it would be best to enclose all of the version numbers in quotes. That will help users who just copy-paste-modify the example without fully understanding the nuance. Then I think the explanation about why can be removed (YAML parsers will truncate...).
(The linked bug seems to concern treating the float 3.0 as the int 3, but even if that was fixed, it wouldn't address 2.10 being treated as 2.1.)
Please let us know if you are willing to make this change!
|
I also opened #14764 to address this more generally |
While I opened the PR I can't make those changes as the branch is owned by @MSP-Greg , but I'm sure he can make em' |
|
Note that 2.10 will never exist as a Ruby version, and it's extremely unlikely there would be any |
|
A stale label has been added to this pull request because it has been open 7 days with no activity. To keep this PR open, add a comment or push a commit within 3 days. |
|
@MSP-Greg are you able to do the requested change (#13418 (review))? If not, I can probably open up a new PR from my fork |
|
I wrote this specifically directed towards Ruby users, and Ruby is often people's first coding language (bootcamps, Rails, etc). Beginners are also unfamiliar with CI systems. I didn't want to imply anything was wrong, just point out differences. So, I'm happy with the PR. |
|
@skedwards88 I made the requested changes in #15240, please review that one instead |
|
Closing in favor of #15240 |
Why:
The wildcard doesn't work in setup-ruby: ruby/setup-ruby#251
What's being changed:
Docs on how to build and test with Ruby on GitHub Actions
Check off the following:
Writer impact (This section is for GitHub staff members only):
Credits to @MSP-Greg for these changes!