Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How about changing interpretation of version string #447

Open
znz opened this issue Jan 17, 2023 · 5 comments
Open

How about changing interpretation of version string #447

znz opened this issue Jan 17, 2023 · 5 comments

Comments

@znz
Copy link
Member

znz commented Jan 17, 2023

Many users who wants use 3.0.x write ruby-version: 3.0 by mistake.

3.0 interpreted as 3 on GitHub Actions.

For example, following workflow step prints 3 only.

        env:
          env_var: 3.0
        run: |
          set -x
          echo ${env_var}

So I propose changing the meaning of 3 (and 3.0 on workflow files) use 3.0.x, and 3.x (or something) use latest 3.x.x.

After this change, many users can write 3.0 intentionally, and some (probably less) users who want use latest 3.x.x can write 3.x or something instead.

@znz
Copy link
Member Author

znz commented Jan 17, 2023

In actions/runner#849 , 3.10 is another problem.
And ruby's yaml parser also parses 3.10 as 3.1 too.
But ruby's yaml parser parses 3.0 as 3.0, so it is more important difference.

@eregon
Copy link
Member

eregon commented Jan 17, 2023

I thought about this too in the past, but it means there is no way to express "Ruby >= 3 < 4" then, i.e. Ruby 3.x.
I'm kind of negative to introduce such hacks and exceptions, because it can lead to more confusion and inconsistency.

I still think this is a bug of the GitHub Actions YAML parser, because it can know the difference but doesn't use it.
No idea if it will ever be fixed though.
An alternative might be if an action can get its inputs as the original strings in YAML, not parsed to numbers or anything. That would also work. core.getInput() is already always a string, but it is value.toString vs the original string.

.10 is not an issue as few Ruby versions have a .10, and those that do have it have it as patch so then it's not a float anymore anyway (e.g. 2.4.10).

@eregon
Copy link
Member

eregon commented Jan 24, 2023

I filed actions/toolkit#1320, if that's done that would be enough.

@eregon
Copy link
Member

eregon commented Jan 24, 2023

Another idea is maybe we could warn when we get 3 as the input.
And then we could say use ruby-3 if you really want CRuby >= 3 < 4, that's actually a fairly simple alternative way to express CRuby >= 3 < 4.

gael-ian added a commit to gael-ian/vagrant-bindfs that referenced this issue Feb 26, 2023
gael-ian added a commit to gael-ian/vagrant-bindfs that referenced this issue Feb 26, 2023
* Configure Github Actions
* Add status badge to README
* Express Ruby versions as string to work around ruby/setup-ruby#447
* Add Gemfile.lock to repository
@eliduke
Copy link

eliduke commented Mar 6, 2024

In actions/runner#849 , 3.10 is another problem. And ruby's yaml parser also parses 3.10 as 3.1 too. But ruby's yaml parser parses 3.0 as 3.0, so it is more important difference.

I was just reading about this as well, looks like the solution is to just wrap it in single quotes as such:

env:
  env_var: '3.0'

Should fix the problem for now at least!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants