Should we deprecate this action?

[eregon]

In actions/starter-workflows#448 (comment), @chrispat said:

I don't see a reason to have two different workflows and I also expect that we will deprecate actions/setup-ruby.

I think this is a good idea.
Currently I noticed several cases where people are confused between ruby/setup-ruby and actions/setup-ruby (this action).
For instance ruby/setup-ruby#52 (comment).

As a disclaimer I'm the maintainer of ruby/setup-ruby.
I see ruby/setup-ruby as a superset of actions/setup-ruby:

• Access to essentially all Ruby versions, including alternative implementations, development builds, etc. That's 59 versions vs 3-4 for this actions/setup-ruby. Many Ruby projects or projects using Ruby want to pin to a specific teeny version.
• Automatically install an appropriate Bundler (opt-out)
• Automated caching of bundle install (opt-in)
• Maintained actively
• ruby/setup-ruby is the Ruby starter workflow

So, do you agree we should deprecate this action?
If so, how would the deprecation be implemented in practice?

[DannyBen]

I am one of the "cases that got confused" :)

I for one definitely think there should be one "official" action for key tasks, although I know it is not always possible - since there may be conflicting opinions as to who is responsible for each of these official actions.

For what its worth, I was hoping that GitHub Actions would take an approach similar to what DockerHub is doing, which is to have a special class of actions that are official and verified (on DockerHub its all the images that do not have an organization, like mongo and ubuntu etc.).

I wish that in GitHub actions I could do:

steps:
- name: Setup Ruby
  uses: ruby

and it will go to the formal action, which - ideally - is maintained by the Ruby people (since they know it best, and are invested in it) and "approved as the formal one" by the GitHub team.

Having actions that are official like this, helps to put formal security related guidelines in an organization, such as "Only use official and verified Actions".

[eregon]

it will go to the formal action, which - ideally - is maintained by the Ruby people (since they know it best, and are invested in it) and "approved as the formal one" by the GitHub team.

That seems unfortunately impossible, as the rule seems to be that actions under github.com/actions can only have GitHub staff as (code) maintainers: #44 (comment)

ruby/setup-ruby being the Ruby starter workflow will probably be as far as it gets in terms of official.
I noticed on the marketplace ruby/setup-ruby is marked as

Verified creator
GitHub has verified that this action was created by ruby.

Maybe that's good enough to fit your "Only use official and verified Actions" guideline?

I think if one trusts Ruby (e.g., building & running MRI) then one can trust actions made by the Ruby org on GitHub.

But I see your point that there is no simple rule like "actions made by GitHub".
On the larger scale there are very few actions under github.com/actions in comparison to actions made by the community, so I think "only actions made by GitHub" is too limiting for many usages.

[DannyBen]

Maybe that's good enough to fit your "Only use official and verified Actions" guideline?

Absolutely. And the "Verified by GitHub" is also a good addition.
It seems that now there are at least three "classes" of actions:

1. Actions made by GitHub (which at first, I thought this list will grow rapidly)
2. Actions made by the Product Owner or Authority (Amazon for AWS actions, Ruby for Ruby actions)
3. Actions made by "some random developer on GitHub".

I believe that, like me, other people who are responsible for guidelines in their organizations, can easily point to the first two types as "approved for use".

[eregon]

@thboop @eileencodes Any thoughts on this issue?

Here is a recent example of the confusion this is causing: ruby/setup-ruby#92 (comment)

[eregon]

One more example: actions/runner-images#281 (comment)

[eregon]

From what I've seen this action is already no longer published on the marketplace and ruby/setup-ruby is what people get when using the starter workflows.

I wonder why people still come to this action and then get confused why so few versions are available. Maybe they simply look at https://github.com/actions/ ?. If so, maybe a good way to is to add [DEPRECATED] or so in the description, or/and add a mention in the README that https://github.com/ruby/setup-ruby is recommended instead by having a lot more Ruby versions and more features (as well as being maintained more actively)? WDYT?

[alepauly]

@eregon Yes! I think we should deprecate this one, thanks for bringing it up and sorry for the delay in us noticing it. We'll work on a deprecation plan to minimize workflows that could break.

As an aside, I think it would be great to make it so ruby/setup-ruby could take advantage of whatever it's installed on the image but that's a different topic, I'll open an issue in ruby/setup-ruby in the near future to discuss that one.

[sandstrom]

We'd prefer to only using official actions (or our own).

Since there are already actions/setup-node, actions/setup-go, actions/setup-python, etc (examples here). Would it be a better idea to move ruby/setup-ruby into this namespace?

I think it would make sense for Github to maintain basic, trusted setup actions for a bunch of common languages.

[dentarg]

Would it be a better idea to move ruby/setup-ruby into this namespace?

Doesn't seem to be possible, see #80 (comment)

[chrispat]

No we shouldn't move a community driven action into this namespace. We should limit it to only actions supported by GitHub employees directly. This action should be deprecated and removed in favor of ruby/setup-ruby