Chart: added basic support git-sync v4.0.0+

[mnacharov]

Allow to use git-sync v4.0.0+: specify new variables if a new version is specified

closes: #32335

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[jedcunningham]

We can't just change what key we use like this, another breaking change.

[mnacharov]

I think that this breaking change must be made by anyone who wants to use git-sync v4.0.0+, but we can keep git-sync tag =~v3.9 in chart's values.yaml.

but for those who put v4.0.0+ in their values file it's necessary to upgrade their credentialsSecret as well

[jedcunningham]

No, we don't have to change the key in the secret, just the env var we are mounting it to (line 265). That makes it a non-breaking change. Alternatively, we could support both (edit: maybe, didn't think that one through completely).

[mnacharov]

@jedcunningham review please

[jedcunningham]

Actually, in these templates we can do whatever we want (no backcompat concerns). So let's just keep the v4 one.

[mnacharov]

ok

[jedcunningham]

I don't think we can just compare against the tag like this. Sure, works for the upstream images, but we shouldn't restrict how folks can retag in their own registry.

If we want to do branching logic like this, we'll have to add an equivalent to airflowVersion somewhere.

[jedcunningham]

Alternatively, can we just set both the old and new env vars? A little messier, but no new version config either...

[jedcunningham]

Moving @hussein-awala's question here from a resolved thread, I'd say that will dictate whether the old + new approach is palatable:

Will we have deprecation warning if we provide both old and new styles to git-sync v4.0.0+ image?

[mnacharov]

yes, we will have deprecation warning if we provide both old and new env vars

[jedcunningham]

Yep, this is an example of why inferring the version from the tag isn't safe.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.