community-ci: declare "early CI"

[alafanechere]

What

We want to run some CI checks on community PRs automatically.
For safety reasons these checks would be the one which:

• Do not require secrets
• Do not require connector code execution

This PR makes the static checks (a.k.a qa checks) and version increment checks run automatically on community PRs.

How

• Declare an "early CI" job in the community ci workflow
• Run airbyte-ci connectors test --only-step=qa_checks --only-step=version_inc_check
• Modify airbyte-ci to customize the name of the global status check that are emitted by a test command

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
airbyte-docs	⬜️ Ignored (Inspect)	Visit Preview		May 2, 2024 7:26am

[alafanechere]

• community-ci: declare "early CI" #37690 👈
• airbyte-ci format: make most inputs optional in run-airbyte-ci #37683
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @alafanechere and the rest of your teammates on Graphite

[natikgadzhi]

I love that we're improving, and I love pre-ci idea. Approving to move forward.

That said, two pieces of feedback I have for you are:

• Please do not discard all PRs to CDK and to airbyte-ci. I don't think you have to do this. Perhaps we can only do this for pre-ci, but keep airbyte-ci directory from fork for full CI, so we get security, but keep ability to test airbyte-ci changes on demand with approval.
• Ditto formatters, while separate PR, formatters should also run without priviledges and automatically without human approval I think.

[natikgadzhi]

This will make it impossible to test any changes to airbyte-ci itself, and I don't think this is necessary.

[alafanechere]

Please do not discard all PRs to CDK and to airbyte-ci. I don't think you have to do this. Perhaps we can only do this for pre-ci, but keep airbyte-ci directory from fork for full CI, so we get security, but keep ability to test airbyte-ci changes on demand with approval

I'm thinking of creating a different workflow for CDK and airbyte-ci contributions.
My plan is to restructure our workflow to reduce the number of workflow files to simplify maintainance and shared logic.

I'd ideally like to have:

• A connector specific workflow which would run all required checks for connectors PRs, both on forks and not on forks
• An internal packages specific workflow