-
Notifications
You must be signed in to change notification settings - Fork 847
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
Splitting VVV code in Vagrantfile into classes #2641
Splitting VVV code in Vagrantfile into classes #2641
Conversation
This is an unusually large commit that should untangle some of the additional Ruby code run by the Vagrantfile, before the `Vagrant.configure` block is run. - Moving functionality related to VVV that is run before the `Vagrant.configure` block into a separate Ruby module and classes - The resulting classes and methods now follow the Ruby Style Guide - Implementing simple and reasonable Rubocop ruleset - Adding a Rubocop Github action - Adding a `.ruby-version` file indicating the Ruby version currently used by Vagrant (2.7.6) - Few if any functional changes have been introduced intentionally - Further code cleanup The following classes were created: - `VVV::Info` - Fetches info on the platform and environment - `VVV::Config` - Reads and processes the config file - `VVV::SplashScreens` - Displays splash screens - `VVV::Bootstrap` - Indicates when to display splash screens - `VVV::Migrate` - Handles config file and database migrations Caveats: - This covers what happens before `Vagrant.configure` - The cleanup is required to keep the Ruby code maintainable and to facilitate further development. Bugfixes: - The non-functionning `Vagrant.has_plugin?` may be replaced by `VVV::Info.vagrant_local_plugins` and `VVV::Info.vagrant_global_plugins` To be tested: [ ] Config migration [ ] Database migration [ ] Splash screens and [ ] Config defaults [ ] Config processing and backwards-compatibility [ ] Github action for Rubocop [ ] Different host platforms and architectures
|
f4e8ff7
to
c024acf
Compare
A rubocop Github action has been introduced again, using a shell line this time. |
I still need to test it but I have doubts about the folder structure. As we are working/thinking on a custom launcher and docker support a generic lib folder with just the stuff for vagrantfile can create confusion. It is better to move it in a subfolder like |
c024acf
to
eb34890
Compare
@Mte90: One of the aims here is to facilitate being able to end up with a more portable codebase that could be used in a different context, such as pre-loading things for Docker provisioning in the future, while keeping things such as configuration management, migrations and the general look and feel. Replacing calls to class methods in the It was @tomjn who suggested adding a The I'd rather suggest removing the dot from the I understand that this is a large changeset but the intention for the time being is not to introduce breaking changes in this PR while making it a foundation for future portability and maintainability, which I'll be happy to help with as long as we're on the same page in general, as I've been aware of the need to move away from virtualisation to containers for a couple of years. Cleaning up what's inside the |
The code is perfect as it is but the problem to me is the code organization just it. Because who will use Docker don't need ruby and probably in the future neither Vagrant as they are migrating internally to pure golang implementation (now various things are supported like for the Vagrantfile). |
I actually like that In an ideal world, a user opens the VVV folders and all they see are their sites. As for moving away from vagrant, I think it'll always be there, the vagrant + virtualbox combination has served us well. What doesn't serve us well is a monstrous long vagrantfile. So perhaps moving the ruby code down from For the planned golang CLI tool, I still expect that to call |
So, any concrete suggestions about where to place this? Naming things is not something I'm good at, but perhaps referring to this as a library/gem then and galling it something like What about |
To me |
+1 to a |
This job failure looks like it needs work: https://github.com/Varying-Vagrant-Vagrants/VVV/actions/runs/3427707635/jobs/5711040160 When provisioning, things go in this order:
The "sources" clone the repos and pull down updates, but they don't run the provisioners, so there's a separation between execution and fetching/updating
|
process_utilities | ||
process_utility_sources | ||
process_extensions | ||
process_extension_sources |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these are the wrong way around
process_utilities | |
process_utility_sources | |
process_extensions | |
process_extension_sources | |
process_extension_sources | |
process_utility_sources | |
process_extensions | |
process_utilities |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
though it is just linting so this isn't as important as it looked when I read it
def self.vagrant_local_plugins | ||
json_file_path = File.join(vagrant_dir, '/.vagrant/plugins.json') | ||
return [] unless File.file?(json_file_path) | ||
|
||
json_file = File.read(json_file_path) | ||
json_hash = JSON.parse(json_file) | ||
|
||
json_hash['installed'].keys | ||
end | ||
|
||
def self.vagrant_global_plugins | ||
json_file_path = File.join(Dir.home, '/.vagrant.d/plugins.json') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in theory we can query vagrant itself for this but this seems more logical, my only concern is wether removing the plugins would actually change this since we aren't directly checking for the plugins. Likewise for vagrant go this may not be how that info is stored
I'm a little puzzled having read through the changeset why it didn't run the source provisioner for the extension in the clean provision, perhaps there's a bug in the workflow 🤔 |
@tomjn: Perhaps there's a regression related to what I had considered to be a formatting or style issue. I'll have a look in the next couple of days in addition to anything else that you spotted. Any chance to allow me to re-run those provisioners/jobs if I need to? |
@aldavigdis I'm not sure that's related to this PR, checks should auto-rerun if not poke me |
@tomjn I'll have a better look after the weekend. I was just assuming that some checks were simply assumed to fail. |
I'd like to revisit this, if only to take parts of it into |
@aldavigdis I was hoping to cherry pick some things out of this and keep the commit credits, particularly the rubocop/linter stuff, I can do that myself but it'll have my name on it :( do you want to do a follow up PR with just those changes? I'm keen to move forward with the changes, but it's a bit much to do all at once all together |
This is an unusually large commit that should untangle some of the additional Ruby code run by the Vagrantfile, before the
Vagrant.configure
block is run.Vagrant.configure
block into a separate Ruby module and classes.ruby-version
file indicating the Ruby version currently used by Vagrant (2.7.6)The following classes were created:
VVV::Info
- Fetches info on the platform and environmentVVV::Config
- Reads and processes the config fileVVV::SplashScreens
- Displays splash screensVVV::Bootstrap
- Indicates when to display splash screensVVV::Migrate
- Handles config file and database migrationsCaveats:
Vagrant.configure
Bugfixes:
Vagrant.has_plugin?
may be replaced byVVV::Info.vagrant_local_plugins
andVVV::Info.vagrant_global_plugins
To be tested:
Checks
develop
branch not thestable
branch.