Replies: 1 comment
-
A very simple solution would be to just make the environments their own homebrew repo. Though that wouldn't play super nice with people not using homebrew. I do like the idea, but I don't find it super important either. We can release as many tiny versions as we want because people don't generally want to be on older versions of Warden. That might not always be the case, and it is certainly true that people do stay on older versions just out of not updating. What I think is more worthwhile of attention for this kind of use case is to expand the ability of environments for non-Warden maintained versions. Warden has always been part and parcel focused on Magento, with other environments submitted getting a kind of meh because I don't work with those and I'll be very bad about keeping them up to date. Having some way to pull in environment types could make Warden more useful without increasing maintenance |
Beta Was this translation helpful? Give feedback.
-
The idea here is to take our current environments and move them to another repository, or alternative location. Then environments are either cached locally or retrieved on-demand.
Things to consider about not distributing these with the full warden release:
-- Environments could be added or updated without requiring a new Warden release
-- How do we ensure the security of the downloaded environment isn't tampered with?
-- Clone the repository?
-- Create releases that are downloaded and extracted locally?
My initial thoughts are:
wardenenv/environments
${WARDEN_HOME}/environments
directorygit pull
)warden svc up
warden env-init
to use cloned repo fileswarden env up
to use cloned repo filesWould love feedback on the approach, or if there are things missing or other things that may need to be included here.
Beta Was this translation helpful? Give feedback.
All reactions