You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regularly we have people trying to update old apps hitting the 404 for the old sandstorm/jessie64 box. vagrant-spk doesn't use that box anymore, but the scripts in the .sandstorm directory for random old apps don't know that.
My advice is generally to do a new setupvm in another folder, and grab the Vagrantfile and global-setup.sh from it and overwrite what's in the app directory. I think we should have a command like maybe vagrant-spk updatevm which overwrites those two files in your existing app's .sandstorm directory with whatever vagrant-spk generates for new apps.
I do not think we can do this for the stack files because apps customize them too much. But some will not break at all (especially if they used the diy stack). Apps shouldn't ever be tampering with the Vagrantfile or global-setup.sh, so I think it would be relatively safe to do this, but if we create this command we should also add comments to these two files to specify explicitly that people should not tamper with them, and maybe have a warning step when executing it that it will overwrite those files.
The text was updated successfully, but these errors were encountered:
If we take the position that app developers should never modify these, why make them a durable part of the app's repository at all? We could have vagrant-spk supply the current versions of those files at run time.
The biggest issue is that a lot of stacks are specific to the Debian version vagrant-spk uses. (We should try to move away from this, ideally.) But apart from the unfortunate reality that many apps contain broken versions of these files right now, if you want to rebuild an app without modification, you should use the version of Debian that it was built with originally, not the latest one vagrant-spk supports. So the reason to include them would be reproducibility, mostly.
But in the case where you want to upgrade to the latest VM vagrant-spk supports, or the one that you originally built with is missing or broken, I feel like we should have a handy command to clobber over what was there.
As a note, when thinking about this, I decided upgradevm would be a better name for this, because updates are generally thought of as less breaking than upgrades, and in many cases, this command would be used to literally move to a newer version of Debian.
Regularly we have people trying to update old apps hitting the 404 for the old sandstorm/jessie64 box. vagrant-spk doesn't use that box anymore, but the scripts in the .sandstorm directory for random old apps don't know that.
My advice is generally to do a new setupvm in another folder, and grab the Vagrantfile and global-setup.sh from it and overwrite what's in the app directory. I think we should have a command like maybe
vagrant-spk updatevm
which overwrites those two files in your existing app's .sandstorm directory with whatever vagrant-spk generates for new apps.I do not think we can do this for the stack files because apps customize them too much. But some will not break at all (especially if they used the diy stack). Apps shouldn't ever be tampering with the Vagrantfile or global-setup.sh, so I think it would be relatively safe to do this, but if we create this command we should also add comments to these two files to specify explicitly that people should not tamper with them, and maybe have a warning step when executing it that it will overwrite those files.
The text was updated successfully, but these errors were encountered: