Merge specialized PR workflows back into one configuration file

[Mpdreamz]

This refactors our PR builds so that we move back into a single workflow.

This PR removes the specialized -docs.yml workflows while retaining the fast path for only doc changes.

A follow up PR will also remove the companion -reporter.yml workflows.

This PR also rearranges our job dependencies a tad to be a tad more ecologically friendly 🌴 by ensuring we don't fail on formatting changes first before kicking off the heavier integration tests. We can extend this later with more build and linting fast failures.

[v1v]

I'm biased toward the former approach with the paths-ignore—it's a native GitHub Actions approach. Unless I miss the rationale behind this change, I prefer to avoid using tj-actions/changed-files@v44 to reduce the requirements of a third-party dependency.

Besides, I see the number of conditionals at the step level has increased, which I think makes things too ad hoc and hard to debug.

I'm not blocking this, but could you help me understand whether the other changes can stay so we can keep the —docs pattern?

[Mpdreamz]

@v1v hear you on the if conditions and the path ignore being more native. It looks worse than it is most are only at the single job level, only for required jobs they need to be on each step to short circuit properly. Hoping to refactor these to a composite action requiring only a single if: in a follow up PR.

Through this I also hope to minimize the heavier tests we run on PR's e.g only run azure/iis/profiler tests on PR's if they have relevant changes while still always running them on main. That gets more complex quickly with the -<changeset>.yml pattern.

[Mpdreamz]

#2365 relates to this to further simplify our CI workflows configuration.

It removes the test composite action and a third party dependency test reporting workflow.

[stevejgordon]

LGTM

[v1v]

I'm not blocking this. However, I'm biased in using the native GitHub way as it was.

What's the genuine reason for changing this? IIUC, was the only-docs approach already working fine, or did I miss something? If it's about centralising one GH workflow with all the steps. IMO, specialised PR workflow is a better approach to reduce side effects if changing one and breaking all, and it is easy to maintain and read.

Also, I still think the step conditionals are a bit complicated, and I prefer job conditionals

We enabled back in the days a centralised post-job to act as the GitHub check branch protection:

• https://github.com/elastic/apm-agent-python/blob/main/.github/workflows/test.yml#L158-L170

That could help centralise all the conditionals in one place.

[Mpdreamz]

Thanks @v1v the main reason was that I also wanted to make the azure tests conditional on change sets while still only being run after lint/build.

It could be a separate workflow being triggered by another: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-a-workflow-based-on-the-conclusion-of-another-workflow

[v1v]

LGTM, with just a minor comment

[stevejgordon]

LGTM