Environment variables defined in .lagoon.env.$BRANCHNAME are not available in post rollout tasks

[mxr576]

Describe the bug

In a Drupal project, we rely on a 3rd-party service connection that requires environment-specific, non-sensitive configuration stored in an environment variable within a .lagoon.env.$BRANCHNAME file, committed to the repository.

This week, during a data migration process, we encountered unexpected behavior. The migration utilized:

1. A custom Drush command
2. A hook_post_update_N() update hook executed as part of a [post rollout task](https://docs.lagoon.sh/concepts-basics/lagoon-yml/#post-rollout-tasks-post_rolloutirun).

While the connection to the 3rd-party service worked correctly via the UI and Drush command, the migration failed during the hook_post_update_N() execution. Upon investigation, we found that the environment variable was not accessible during the post rollout task phase, and we have technical evidence to confirm this.

To reproduce

Steps to reproduce the issue:

1. Define an environment variable, e.g., FOO="BAR", in .lagoon.env.master.
2. Create a hook_post_update_N() function in an enabled Drupal module that checks or asserts the value of the FOO environment variable.
3. Deploy the application and observe the behavior during the post rollout phase.

Expected behavior

Environment variables defined in .lagoon.env.$BRANCHNAME should be available during post rollout tasks, ensuring no failures when accessing them in a hook_post_update_N() function or similar operations.

Screenshots

N/A

Additional context

N/A

[shreddedbacon]

Related #574?

A possible workaround #574 (comment) or try setting the shell of a pre/post rollout task as bash to see if changing the shell used allows it to correctly source the variables.

The reason the tasks don't access the variables is related to the image in use. Some shells (sh) don't seem to source the .bashrc file when the build execs into the pod to run the task. But using bash as the shell may.

Alternatively trying the workaround in the above issue forces your task to consume the /home/.bashrc that exists in our commons image that gets added to all our images. This only applies to images we provide though.

Since the tasks run inside the container that is built, we can't assume that the /home/.bashrc will always exist if someone isn't using one of our base images.

I guess we need to document this behaviour better.