GH-50133: [CI] Make extra labels entirely manual

[pitrou]

Rationale for this change

Our "Extra" labels for CI are currently both manual and automatic:

• manual, such that a committer can add a label to force an additional of CI jobs to run on a PR
• automatic, such that specific file changes can also force those additional CI jobs to run

However, the two mechanisms can conflict with each other, when an Extra label is manually added by a committer, but none of the file changes match. The label can then be later removed by the automatic labelling bot.

What changes are included in this PR?

Make the "Extra" labels manual-only.

Are these changes tested?

N/A.

Are there any user-facing changes?

No.

• GitHub Issue: [Dev][CI] Extra labels are confusing #50133

[github-actions]

⚠️ GitHub issue #50133 has been automatically assigned in GitHub to PR creator.

[pitrou]

Ping @raulcd @kou

[pitrou]

"Extra: C++" does not seem to be working as expected here?

[raulcd]

LGTM, as seen on the other issue, should we also avoid forcing a build if the workflow file has changed?

arrow/.github/workflows/check_labels.yml

Lines 74 to 79 in cffe22d

	git diff --stat origin/${GITHUB_BASE_REF}..
	if git diff --stat origin/${GITHUB_BASE_REF}.. | \
	grep \
	--fixed-strings ".github/workflows/${PARENT_WORKFLOW}.yml" \
	--quiet; then
	echo "force=true" >> "${GITHUB_OUTPUT}"

This might force builds when the PR is old and new changes are merged on main.

@kou what do you think on that case?

[raulcd]

"Extra: C++" does not seem to be working as expected here?

doesn't it still require changes on the defined path? We could force check on all (remove the paths as we do for cuda_extra.yml)

    paths:
      - '.dockerignore'
      - '.github/workflows/check_labels.yml'
      - '.github/workflows/cpp_extra.yml'
      - '.github/workflows/cpp_windows.yml'
      - '.github/workflows/report_ci.yml'
      - 'ci/conda_env_*'
      - 'ci/docker/**'
      - 'ci/scripts/ccache_setup.sh'
      - 'ci/scripts/cpp_*'
      - 'ci/scripts/install_azurite.sh'
      - 'ci/scripts/install_gcs_testbench.sh'
      - 'ci/scripts/install_minio.sh'
      - 'ci/scripts/msys2_*'
      - 'ci/scripts/util_*'
      - 'cpp/**'
      - 'compose.yaml'
      - 'dev/archery/archery/**'
      - 'format/Flight.proto'
      - 'testing'

[kou]

should we also avoid forcing a build if the workflow file has changed?

+1