GH-50253: [CI] Force brew bundle installations to use a single cpu via --jobs 1 flag

[raulcd]

Rationale for this change

A change of behavior on the default number of threads used when installing via brew bundle is causing some CI jobs to fail.

What changes are included in this PR?

Revert to the old behavior by using the --jobs 1 flag.

Are these changes tested?

Yes via CI and archery jobs that were failing.

Are there any user-facing changes?

No, I've updated documentation so some users use the same command we are using but not really changes coming from our side.

• GitHub Issue: [CI] Some macOS jobs fail installing aws-sdk #50253

[github-actions]

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

[raulcd]

@kou based on: https://docs.brew.sh/Manpage the --jobs flag:

--jobs

Run up to this many formula installations in parallel. Defaults to 1 (sequential). Use auto for the number of CPU cores (max 4).

That documentation seems outdated and it seems to fail related to this change of default behavior on brew:

• Default bundle jobs to auto Homebrew/brew#22545

Applying --jobs 1 seems to fix the issue, what do you think, should I apply this on the other places where we do brew bundle --file...?

[raulcd]

@github-actions crossbow submit preview-docs verify-rc-source-*-macos-amd64

[github-actions]

Revision: 9e3445c

Submitted crossbow builds: ursacomputing/crossbow @ actions-1c3ad8af77

Task	Status
preview-docs
verify-rc-source-cpp-macos-amd64
verify-rc-source-integration-macos-amd64
verify-rc-source-python-macos-amd64
verify-rc-source-ruby-macos-amd64

[raulcd]

The Doc CI related failures are currently failing on main too, I've opened:

• [CI][Docs] doxygen fails with unsupported xml/html tag <typename> found on /arrow/cpp/src/arrow/util/bit_util.h:249 #50257

[Copilot]

Pull request overview

This PR addresses recent macOS CI failures caused by Homebrew Bundle running installations in parallel, leading to Homebrew cellar lock conflicts. It restores serialized installs by explicitly setting brew bundle to run with a single job (--jobs 1) across CI and the corresponding developer documentation.

Changes:

• Update GitHub Actions macOS workflows to run brew bundle ... --jobs 1.
• Update the verify-rc macOS task to run brew bundle ... --jobs 1.
• Update developer docs and the GLib README to recommend brew bundle ... --jobs 1 to match CI behavior.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
docs/source/developers/release_verification.rst	Aligns release verification steps with serialized Homebrew Bundle installs.
docs/source/developers/python/building.rst	Updates macOS dependency install instructions to use --jobs 1.
docs/source/developers/java/building.rst	Updates macOS dependency install instructions to use --jobs 1.
docs/source/developers/cpp/building.rst	Updates macOS dependency install instructions to use --jobs 1.
dev/tasks/verify-rc/github.macos.yml	Forces serialized Homebrew Bundle installs in verify-rc macOS runs.
c_glib/README.md	Updates GLib macOS setup instructions to use --jobs 1.
.github/workflows/ruby.yml	Forces serialized Homebrew Bundle installs in Ruby CI on macOS.
.github/workflows/python.yml	Forces serialized Homebrew Bundle installs in Python CI on macOS.
.github/workflows/cpp.yml	Forces serialized Homebrew Bundle installs in C++ CI on macOS.
.github/workflows/cpp_extra.yml	Forces serialized Homebrew Bundle installs in extra C++ macOS workflows.

[raulcd]

@tadeja , the llvm issue seems to have been magically fixed here, see the crossbow report above 🤔

[kou]

+1

It makes sense that this is a workaround but can we try the following (install aws-sdk-cpp manually before we run brew bundle`) before we merge this?

brew install aws-sdk-cpp
brew bundle --file=cpp/Brewfile # no --jobs 1

And can we report this to Homebrew? I feel that this is not an expected behavior.