Why are entrypoints specified individually for .profile and not loaded dynamically?

[bryangruneberg]

One of our projects uses a custom entrypoint to set some environment variables. Looking at "~/.profile" I see that the entrypoints are individually sourced and not loaded using /lagoon/entrypoints.sh

This means that adding a custom entrypoint (EG: /lagoon/entrypoints/99-add-a-runtime-var.sh) don't get automatically sourced to the CLI shell environment when accessing the container remotely.

Is there a reason the entrypoints are sourced individually in ~/.profile? Would it not make sense for the ~/.profile to call /lagoon/entrypoints.sh to create a congruent experience for the shell as well as the container runtime CMD environment?

[Schnitzel]

yes, reason is remote(shell) connections. (I've spent countless hours on this and is many years ago, so I hope I remember this correctly).
When you connect to a container through an remote container we need to run some (but not all) entrypoints, for example to generate environment variables. If we would run all entrypoints it would lead to a lot of issues. One example would be the cronjob one, which means you would have a cronjob running inside your remote shell, which is not what we want. Or in some other cases (like mariadb) it would actually start another mariadb process, which would also fail.

If you want to run something during a shell connection I would suggest to add your stuff directly to https://github.com/uselagoon/lagoon-images/blob/main/images/commons/lagoon/entrypoints/55-generate-env.sh or maybe source it from there, as the 55-generate-env.sh file is sourced during a shell connection: https://github.com/uselagoon/lagoon-images/blob/main/images/commons/.bashrc#L10

[bryangruneberg]

@Schnitzel - Thanks for this!

Two follow-ups...

1. Is there value in considering having a /lagoon/cli-entrypoints.sh and a new directory /lagoon/cli-entrypoints/? The cli-entrypoints.sh would source from the new directory, and then the .bashrc only references the one file. In this scenario, if a dev was wanting to add an entrypoint that was run for both CLI as well as , they could either symlink the same file, or even docker COPY the same file to two places. The value for me there is the dev doesn't have to touch 55-generate-env.sh or the .bashrc - both of which could be changed at any point and then downstream images are making changes as well.

2. Either way, should I contribute some docs on how to add a new entrypoint that also runs in the cli? It wasn't immediately clear why my script wasn't running until I checked .profile and saw how it was done.

[tobybellwood]

we've just talked about this, and think that providing an empty XX-profile-source.sh entrypoint that is called both by the startup and ssh entrypoints should work, with the intention that this be either overwritten or appended to.

[bryangruneberg]

nice - that's great @tobybellwood