Restricted AArch64 CI to relevant changes

[vpirogov]

There's no need to run AArch64 CI on changes that are unlikely to affect this platform.

[vpirogov]

The issue with approach taken in this PR is that Github still considers AArch64 CI checks required and prevents PR from being promoted.

[vpirogov]

@theComputeKid, any ideas here?

[theComputeKid]

One solution (but not ideal) is that we add a step in the AArch64 pipeline to read the label and then make a decision based on that to quit successfully early.

Drawbacks:

1. We will still spin up an instance for a few seconds
2. It will still book a slot in the Q
3. It will label the AArch64 as passed even though it was skipped

Advantages:

1. We will only spin up an instance for a few seconds instead of the whole run.

I'm working on a PR to reduce the configs AArch64, should have that out shortly.

[mgouicem]

Stackoverflow suggests to create an action with same name but with opposite condition that would always run successfully (see here)

[vpirogov]

Stackoverflow suggests to create an action with same name but with opposite condition that would always run successfully (see here)

This approach is very limited as 'opposite condition' cannot always be described using trigger path syntax. Conditions suggested in the answer with path: xxx and path-ignore: xxx are not mutually exclusive. A PR touching files matching xxx and not matching xxx will trigger both workflows. This is discussed further down the thread.

[vpirogov]

I would suggest that at this point we make sure that AArch64 CI runs only for relevant changes and figure out how to make it required later. Github developers are aware of our pain.

We are taking the same approach for x64 CI: #2281. I expect codeowners (i.e. people allowed to merge PRs) would use CI as a tool to prevent breaking changes.