[ci] add ppc64le C++ test job

[asifsheikhibm]

Contributes to #7262

Added Power support for cpp workflow.
Added separate job for clang and gcc for ppc64le.

Happy to adjust the workflow based on CI or community feedback.

[jameslamb]

Thanks but I'm not willing to add 3 new C++ CI jobs for this and even more Python jobs, or to maintain support for both gcc and clang on this architecture... that's a big expansion of our CI matrix.

Let's please start with a single cpp-tests job using gcc and then in a follow-up PR a single python-package job also using gcc.

Maybe in the future if we get more demand for this architecture we could expand the CI matrix, but let's please be conservative for now.

[jameslamb]

I've also added a link in the description to #7262. Please do that here on GitHub, it's very helpful for folks to understand the connection between this code change and prior conversations. Helps to answer questions like "why?" and "how does this work?" without anyone having to ask.

[jameslamb]

Does this repo actually have access to those runners?

Looks like these have been waiting to run for 14+ hours so far.

If the repo has access and those are the normal wait times, then we cannot make these jobs something that runs in PR CI. Anything that makes PR CI take longer than 45 minutes would be unacceptable.

[sandeepgupta12]

No, it does not take much time to allocate runners. The GHA team has already verified this from the backend. These jobs are stuck due to permission issues. Could you please review the following permissions:
https://github.com/IBM/actionspz/blob/main/docs/onboarding.md#for-organization-admins-update-runner-groups

[jameslamb]

Ok thanks, I'd missed a setting in the runner group. Just enabled that and pushed an empty commit, let's see if it runs.

By the way, is the runner group name Default something that was created by the GitHub App for these IBM runners? And if not and that's a GitHub default thing, why did these runners end up in it?

In my opinion, they should be in a dedicated runner group with an informative name (PowerPC-runners or similar). Default is too generic, and the settings projects want for these runners may be different from what they want for other runners.

[jameslamb]

They still look stuck, by the way, and the runners show as "offline" in the Default runner group.

What else do I need to do?

[jameslamb]

Ok I see one did get picked up: https://github.com/lightgbm-org/LightGBM/actions/runs/28260135761/job/83733256511?pr=7345

But only 1 so far.

Is there a concurrency limit on these runners? If we can only run 1 job at a time across the whole repo, that would also make me very hesitatnt to add these jobs to PR CI.

[sandeepgupta12]

@jameslamb, We have multiple runners available, which allows us to run several jobs concurrently. There isn’t a repo-wide restriction limiting us to a single job at a time, so adding these jobs to PR CI should not create a bottleneck.

[asifsheikhibm]

Thanks but I'm not willing to add 3 new C++ CI jobs for this and even more Python jobs, or to maintain support for both gcc and clang on this architecture... that's a big expansion of our CI matrix.

Let's please start with a single cpp-tests job using gcc and then in a follow-up PR a single python-package job also using gcc.

Maybe in the future if we get more demand for this architecture we could expand the CI matrix, but let's please be conservative for now.

we have incorporated the review comment, kept only cpp test using gcc and removed clang jobs.
Can you please trigger the workflow again?

[sandeepgupta12]

@jameslamb, can you please review changes?