feat: add support for organization environment variables

[rocketeerbkw]

Checklist

• Affected Issues have been mentioned in the Closing issues section
• Documentation has been written/updated
• PR title is ready for changelog and subsystem label(s) applied

Updates lagoon-remote so that it will make organization environment variables sent by lagoon-core available to the build-deploy-tool.

Closing issues

Part of uselagoon/lagoon#3602

[shreddedbacon]

If we can avoid updating the CRD, that would be my preference. There is a way we can support this without having to update the CRD that would put most of the changes into uselagoon/lagoon and uselagoon/build-deploy-tool.

I'll add some comments to uselagoon/lagoon#3856

[rocketeerbkw]

What's the concern with updating CRDs?

edit: I saw the response in the other ticket, so just asking about CRDs specifically. Why avoid it as a preference?

[shreddedbacon]

What's the concern with updating CRDs?

edit: I saw the response in the other ticket, so just asking about CRDs specifically. Why avoid it as a preference?

If a lagoon-core feature requires a CRD update, then we need to ensure that every communication states clearly that a CRD update is required. This feature now ties a lagoon-core version to a lagoon-remote version.

Where an operator has no control over a lagoon-remote, some other team does, coordination efforts are required to ensure that they update their CRDs at the same time that core is updated. Depending on the feature, this could be acceptable, or breaking. For this specific case, they would not be able to leverage the new organization variables until they updated their lagoon-remote CRDs, even though lagoon-core would provide the ability to configure them. If the team managing the lagoon-remote aren't able to update their remote for whatever reason in a reasonable time, the functionality is broken for how long?

Sometimes CRD updates are unavoidable though, and we can definitely case by case them, which is why the preference is to avoid. The recent v1beta1 to v1beta2 change is an example of something that was somewhat unavoidable, but it doesn't tie the lagoon-remote to a specific version of lagoon-core as the CRD changes were to reduce the scoping of the data stored in the CR. At some stage we will have to remove the v1beta1 CRD too, but again it won't be something that ties it to a specific lagoon-core version.

If we consider future functionality, then we can also consider updating the CRD. Taking this one as an example, we can introduce the organization variables field to the CRD, document that a CRD update is required when installing the version of lagoon-remote that introduces the field, but the actual feature that uses it in lagoon-core is in a subsequent release. This gives people time to have updated lagoon-remote and the CRDs before the feature drops. We then document the minimum required lagoon-remote version when the feature is released in lagoon-core.

My main preference is to avoid, where possible, tying a lagoon-core and lagoon-remote version together specifically.