set support folder to read only in developer container

[gilesknap]

This is to make it clear that its 'prod' and you must use ibek support work-on to make support module changes.

(extracted as separate issue from #71)

[gilesknap]

This is already true for docker users. For podman users it will require an explicit chmod a-w during container build.

Not sure I like this as it precludes doing an in place rebuild after making changes to ibek-support install.sh for example

Can we come up with a better way to indicate prodness ??

[GDYendell]

Not sure I like this as it precludes doing an in place rebuild after making changes to ibek-support install.sh for example

And I guess this is reasonable because the changes to ibek-support are tracked on the host file system? It is just that it needs to regenerate the support module. So is this just not possible with docker and you have to rebuild the container?

[gilesknap]

it is possible with docker - you can do sudo chmod ...

Agree with your point about you made changes to the host file system and just want to re-generate the support module. Probably the strictest way in which to make this work is to have the support source read only and its output folders writable. That's a bit fiddly to achieve but not completely horrible.

[GDYendell]

Do we need to decide now because it will be a big change, or could we revisit this in a few months time when more people have played with it to evaluate how much of an issue it is and rework it at that point?

If there are fiddly ways to workaround the prodness, maybe that should be left to the discretion of the developer and if they don't know how or otherwise just want a simple life they do a container rebuild?

[gilesknap]

This is a visit it at a later date thing.

My inclination is to leave it alone and just make sure people understand containers properly. Therefore know that they can't rely on changes in container filesystems.

For people using docker this is still currently an issue because they can't rebuild support modules but the fix is trivial - we already check for docker and do some chown's here: https://github.com/epics-containers/ioc-template/blob/main/.devcontainer/postCreateCommand#L3C3-L19 and could easily widen the scope of the chown to make docker / podman parity.

BTW doing sweeping chowns inside a container at startup is quite a common pattern (because most container runtimes don't do the clever podman thing of running as root inside only)

[GDYendell]

If we do a chown and a chmod -w, when a developer tries to edit the file, it would warn them that they are editing a read-only file, but things like vim and vscode then prompt to do a force write if you are sure. This is what we have in the iocbuilder generated IOCs currently. Maybe this is a good middle ground to remind people they might lose these changes, but also allow them to do what they need to do?

Edit: Rereading the above. The issue is support module generation will fail in this case, so maybe not useful unless the command can automatically toggle the permissions on and off again? I do worry that people will lose their changes if there is no restriction.

[gilesknap]

Your last answer just made me want to leave it alone again :-)

[gilesknap]

Having left this for half a year and done lots of work inside of generic IOCs I'm thinking that it is OK to work direct on the support modules inside as long as you are very clear on what you are doing and only making small changes.

So I think making things read-only is counter productive. I shall implement #123 so that you can quickly set up a generic IOC with a support module that is mounted in the host file system for when you are actively developing it. I'll also put some suitable warnings in the documentation about loosing your work in the container files system.