reusable gitleaks workflow

[kevin-tricot]

What does this PR do?

In order to centralize our workflows, this gitleaks workflow will be used as a Poc in order to be reused first in app-geo and then apply more quickly to all our backend repositories

See https://github.com/apptweak/app-geo/pull/26 for its usage in another repo

Associated ticket number and/or AirBrake error?

DEX-201

Due Date or Desirable Merge

ASAP

How has this been tested?

Will be tested inside this app-geo PR

Anticipated impact

We should be able to centralize our GH workflows and no more duplicate them in each repo

How do you plan to monitor the change in prod to make sure it's working?

N/A

Checklist

• My code follows the code style of this project.
• I have run tests locally (manual tests and otherwise).
• This has been tested on staging.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• My change includes a database modification
  • I have tested my database modification in staging.
• My change breaks API retrocompatibility.
  • I have notified the frontend developers concerned about this change.
  • I have notified the public API consumers about this change. (DataPi)
• My change touches on some of the following areas: authorizing access to integration data (consoles, search ads, MMP), authentication (including serving or consuming OAuth endpoints), cryptography and security (including generation of secure tokens). If so:
  • I am tagging a senior reviewer to specifically review the security of this change: (flag reviewer here)
• My changes require changes in other components/squads/teams
  • I already did the changes in the other components or notified the responsible people that the changes need to be done
  • The needed changes are already deployed or ready to be deployed

[Dakad]

@kevin-tricot Thanks, that’s exactly what I had in mind as well. That said, I’m not fully convinced this repo is the right place for it 🤔 :

1. The repository is public (and this PR will be as well 😅 ), which isn’t ideal for reusable internal workflows.
2. the goal of this repo is to be a front for AppTweak org on Github.
3. We will also need a clear versioning strategy for these actions. Not necessarily full semver, but at least something like gh-action-1:stable or gh-action-2:alpha so they can be reliably consumed across repositories

I’d recommend creating a private repository (e.g. apptweak-gh-workflows) to centralize and manage our GitHub Actions and give us better control over versioning, reuse, and access.
wdyt?

[kevin-tricot]

@kevin-tricot Thanks, that’s exactly what I had in mind as well. That said, I’m not fully convinced this repo is the right place for it 🤔 :

1. The repository is public (and this PR will be as well  😅 ), which isn’t ideal for reusable internal workflows.

2. the goal of this repo is to be a front for AppTweak org on Github.

3. We will also need a clear versioning strategy for these actions. Not necessarily full semver, but at least something like `gh-action-1:stable` or `gh-action-2:alpha` so they can be reliably consumed across repositories

I’d recommend creating a private repository (e.g. apptweak-gh-workflows) to centralize and manage our GitHub Actions and give us better control over versioning, reuse, and access. wdyt?

Yep, let's do it like that!