search

rvm / rvm1-ansible

The official ansible RVM role to install and manage your Ruby versions.
MIT License
271 stars 136 forks source link

Tests: Verify that 'rvm1_delete' functionality is honoured #221

Closed gildegoma closed 2 years ago

gildegoma commented 4 years ago

This is a first move to try to "fully cover" the features offered by this role.

It is maybe time to consider if this project should continue to implement its specs via Ansible assertions, or adopt some new framework (such as Molecule, TestInfra, ServerSpec, ...).

Bonus Question: Do we really want to keep such feature? If yes, maybe this should deal with a list of rubies... The question is motivated by ongoing debates about Bundler setup being a duty, or not, of this role.

thbar commented 4 years ago

A comment on this by the way:

Bonus Question: Do we really want to keep such feature? If yes, maybe this should deal with a list of rubies... The question is motivated by ongoing debates about Bundler setup being a duty, or not, of this role.

I would personally like to keep this feature in the role, because otherwise I'll have to SSH into my machines.

I do agree though that it should be able to deal with a list of rubies, work idempotently, so that I can keep the list of old rubies in there for some times (particularly useful if I wake up a slightly old vagrant VM which isn't up-to-date ; the old "delete" list will automatically clean up what's been moved to delete).

Kulgar commented 4 years ago

I would personally like to keep this feature in the role, because otherwise I'll have to SSH into my machines.

I kinda agree with Thibaut on this one. Regarding to me, rvm was created to manage rubies (it is named ruby version manager after all).

So, everything that helps people to manage rubies (including removing old rubies), is good to be added to this role I think.

But... rvm wasn't meant to deal with gems installation, gems are handled by rubygems (which is installed by rvm). So, I think bundler (and any other gems) shouldn't be managed by this role as it would add too much complexity as we already faced with bundler.

I don't know if I'm the only one to think that way? :-)

danochoa commented 4 years ago

@gildegoma good job on the PR, it seemed like this was missing from the tests. I don't have any experience with the test frameworks so I can't comment on that, sorry.

I agree, I think rvm1_delete_ruby would be more useful as a list, but I think that could be a breaking change, not sure breaking changes are usually managed here.

gildegoma commented 4 years ago

About improving (or evolving from) rvm1_delete_ruby, I propose the following approach: #222.

pkuczynski commented 2 years ago

@sfgeorge @danochoa @thbar is this ready for merge? Let me know and I will merge it...

thbar commented 2 years ago

@pkuczynski I am in favour of this too ; this is a quality improvement on an existing feature that I still use regularly, so definitely happy to see this.

I feel safer to delete one by one with this, compared to #222.

pkuczynski commented 2 years ago

Perfect. Waiting for build to pass and merging in! :)