fix: bugs on setGitEnvironmentVariables

[fed-sv]

What does this PR do?

Fixes a TypeError: Cannot read properties of undefined (reading 'value') crash in setGitEnvironmentVariables when DD_TAGS is not already set on the lambda function.

Also fixes a minor log message bug in the gitRepoUrlOverride debug statement, which was logging hash instead of gitRepoUrl as the "instead of" value.

Motivation

The else branch of the DD_TAGS check calls lam.addEnvironment(DD_TAGS, ...) to set the sha, then immediately reads back lam.environment[DD_TAGS].value on the following line to append the repo URL. Because lam.environment is a private CDK field accessed via any cast, this read-back is not guaranteed to reflect the value just written by addEnvironment - in particular, it fails when there is a CDK peer dependency version mismatch between the consuming project and the version this library was tested against. The result is a hard crash at CDK synth time that completely prevents deployment.

The root cause is that the two git tags (git.commit.sha and git.repository_url) are set in two separate operations, but the second operation always uses the private field read - even when the first operation went through the public addEnvironment API (the else branch).

Testing Guidelines

Existing unit tests covering setGitEnvironmentVariables continue to pass. The fix is behaviorally identical for the case where DD_TAGS is already set (private field is read, confirmed non-undefined, then appended to - unchanged). For the case where DD_TAGS is not yet set, both git tags are now written atomically in a single addEnvironment call, eliminating the unsafe read-back.

Additional Notes

The unconditional line 71 (lam.environment[DD_TAGS].value += ...) was always unsafe after the else branch because addEnvironment is a public method that may not synchronously update the private environment map in all CDK versions. Combining both tags into a single value in both branches removes this assumption entirely.

Types of Changes

• Bug fix

Check all that apply

• This PR's description is comprehensive
• This PR's changes are covered by the automated tests

[hari-euka]

I raised a PR to address the exact same issue this morning @fed-sv
#597 😄

[fed-sv]

I raised a PR to address the exact same issue this morning @fed-sv #597 😄

ohhh LOL sorry I should have check that! happy for mine to be nuked then 💥. We really need this bug fixed asap 🥺
Thanks 🚀

[fed-sv]

@hari-euka sorry I didn't realize your PR was closed 🤣

[fed-sv]

@avangelillo feel free to close this PR if you guys rather go with #597 👍

[fed-sv]

add missing link to issue. Fixes #596

[TalUsvyatsky]

Thanks for opening this PR, this was ultimately resolved with #601 and https://github.com/DataDog/datadog-cdk-constructs/releases/tag/v2-4.0.0