feat(providers): add infisical secret backend

[DanielHougaard]

This PR aims to add support for Infisical as a custom secrets backend.

The PR is currently a draft until the following gets resolved

• Add authentication check in the internal client to ensure the provider won't lose connectivity with Infisical
• Update the providers/infisical/docs/installing-providers-from-sources.rst doc

Question for the maintainers of Airflow. What is the source-date-epoch field in the provider.yaml file? I wasn't able to find any concrete documentation on this field. Is this something I need to think about?

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[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 Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.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: [email protected]
  Slack: https://s.apache.org/airflow-slack

[eladkal]

Hi Daniel,
welcome to the Airflow community :)

To add a new provider you will need to follow procedure explained in Accepting new community providers doc. Note that for open sourced providers it's simpler process.

What is the source-date-epoch field in the provider.yaml file?

You don't need to worry about that. Its for release manager. When you setup Breeze and run pre-commits it should be handled automaticly.

[DanielHougaard]

Hey @eladkal, thank you for the reply!

You don't need to worry about that. Its for release manager. When you setup Breeze and run pre-commits it should be handled automaticly.

Strange, I have Breeze configured and I ran the pre-commits (I have it installed as a git hook), and the field didn't seem to change. I manually set it to 0 because I was unsure of the value.

To add a new provider you will need to follow procedure explained in Accepting new community providers doc. Note that for open sourced providers it's simpler process.

Got it, thank you for letting me know. A native Airflow integration is something we are consistently hearing from our customers that they wish for us to create. I will open up a discussion, and hopefully we can get this merged into prod 🙏

[potiuk]

Got it, thank you for letting me know. A native Airflow integration is something we are consistently hearing from our customers that they wish for us to create. I will open up a discussion, and hopefully we can get this merged into prod 🙏

If it's just for YOUr customers and YOU hear what they want, it's far more likely that it's YOU who should release and maintain the provider. I personally have never heard of infiscal and one of the criteria to accept a provider is "is it popular enough that we as community want to take the burden of maintaining it", another is "do we have maintainers who are familiar with the integraiton".

I don't think your provider is going to get throug either of the gates personally so you might save yourself time on trying to submit it here but you should - more likely - just release and maintain the provider on your own. You can read about it the providers doc, including links to past discussions where we accepted or did not accept other providers so you might want to make sure to read those carefully. There are also links to the "ecosystem" page where quite a number of 3rd-party providers are listed.