-
Notifications
You must be signed in to change notification settings - Fork 222
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
Add initializeCommand support to features #428
Comments
Hi 👋 Thanks for bringing this up, when lifecycle hooks were first introduced for Features, |
Totally agree, how about this:
For example: "features": {
"somefeature": {
"allowToRunInitializeCommand": true
}
} Not that good, I believe there'll better solutions, but I think |
Such a feature would also be helpful in implementing my use case with minimal user interaction and re-usability through devcontainer-features. My use-case: Regarding security, afaik:
If I were a malicious feature I would be able to do everything I need to escape the container or leak host info already. It would be more of a dev protection to not accidentally modify the host. So more a safety than security feature to prevent that. But if a feature decides to use any of the above settings it already must be sure to not leak or damage the host system by accident too. Current implementation:
Alternative workarounds:
Solutions improving my usecase:
Edit: Also a setting if after completion a container restart is required would be nice. Best Regards, Markus |
As a reference I know implemented my example use case how I am currently able to achieve it: https://github.com/AIT-Assistive-Autonomous-Systems/devcontainer_features/tree/main/src/add-groups |
initializeCommand
is a very useful lifecycle hook and it's the only way I found to run commands on the host machine, anddevcontainer-feature.json
does not support it, could it been supported in the future?The text was updated successfully, but these errors were encountered: