Skip to content
This repository has been archived by the owner on Feb 9, 2021. It is now read-only.

Ruby version removed without bumping major version #51

Closed
chrisseaton opened this issue Jan 17, 2020 · 12 comments
Closed

Ruby version removed without bumping major version #51

chrisseaton opened this issue Jan 17, 2020 · 12 comments

Comments

@chrisseaton
Copy link

I pinned to setup-ruby@v1 and Ruby 2.6.3, but at some point 2.6.3 disappeared. Could you bump the major version of this action when you make a breaking change such as removing a Ruby version? Otherwise workflows just stop working even though I didn't change any configuration.

@garriguv
Copy link

Hopefully not for too much longer :) #49

Also, 2.6.5 works if you're wondering.

lawrence-forooghian added a commit to dxw/transition that referenced this issue Jan 17, 2020
2.6.3 seems to have disappeared from GitHub Actions [1] so the CI builds
are failing.

[1] actions/setup-ruby#51
lawrence-forooghian added a commit to dxw/transition that referenced this issue Jan 17, 2020
2.6.3 seems to have disappeared from GitHub Actions [1] so the CI builds
are failing.

[1] actions/setup-ruby#51
@bryanmacfarlane
Copy link
Member

Bumping the major version would do no good. It's the VM image that removed 2.6.3.

actions/runner-images#281

@chrisseaton
Copy link
Author

Do you know if we can pin to a version of the VM image then? I want a build that will work both today and tomorrow.

@bryanmacfarlane
Copy link
Member

Nope. It slides forward and what the VM script that builds that image happens to do is pull latest minor version. I suggested in the issue ☝️ that it's additive

I updated the readme on this action in accordance to say effectively, you can only bind to minor until they change that.

And yes, #49 will allow it to pull JIT which means that your build won't break, it just might get 10 seconds slower when an older version rolls out of the cache.

@youhanaNaseim
Copy link

@chrisseaton thanks for the feedback totally appreciate it. Apologize for the inconvenience this has caused. In general pinning to a minor version and not a patch version similar to what we have done here https://github.com/actions/setup-ruby/blob/master/.github/workflows/versions.yml should be enough to ensure your workflows continue to work. We do not remove minor versions from the VM images.

Your suggestion about pinning to a VM issues (after we version them somehow) is a great suggestion and is something on the team's backlog we do not have an ETA for that yet though.

I hope this works for you and apologies for the inconveniences this has caused.

@chrisseaton
Copy link
Author

In general pinning to a minor version ... We do not remove minor versions from the VM images.

Ah ok if that's an option I'll do that, thanks.

@bryanmacfarlane
Copy link
Member

@chrisseaton - I would be really interested in how important exact version binding is. Specifically, older patch versions.

@chrisseaton
Copy link
Author

In my use-case some internals of MRI that I depend on change in patch versions.

@chrisseaton
Copy link
Author

...and hypothetically, a patch version could introduce a new bug that blocks you.

@MSP-Greg
Copy link
Contributor

Re changes from one teeny build to another, see a few possibilities at actions/runner-images#281 (comment).

Also, teeny releases often have backports from ruby master, and, although not common, sometimes the backports aren't complete or correct.

@bryanmacfarlane
Copy link
Member

@chrisseaton - also note #49 which would be a solution to your issue. Between actions/runner-images#281 and #49, it covers what you need. Is it OK to close this as a dupe of #49?

@bryanmacfarlane
Copy link
Member

Tracking in actions/runner-images#281 (comment)

@chrisseaton - if this didn't address your question, let us know and we can reactivate.

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

No branches or pull requests

5 participants