SkipConditions: join multiple skip messages

[rexmhall09]

Join multiple skip messages with ", " instead of displaying only the first
message. This ensures all skip reasons are shown when multiple apply
(e.g. "Not maintained, Archived upstream").

Also update the output formatting for both skipped and non-skipped
statuses to improve consistency.

A test was added to verify that multiple skip messages are joined and
displayed correctly.

Codex was used to help speed up implementing the change and drafting the
update. The code and tests were manually reviewed and verified locally,
and brew lgtm was run to ensure all checks pass (on my machine).

(this is a slightly new version of a pull request I just closed with a few fixes)

[Copilot]

Pull request overview

Improves livecheck skip/error output so that when multiple messages are present, all reasons are displayed (comma-separated) instead of only the first message, and adds a spec to cover the joined-message behavior.

Changes:

• Join multiple :messages entries with ", " when printing skip/error information.
• Update print_skip_information output to use the joined message string for both skipped and non-skipped statuses.
• Add RSpec coverage for multi-message output formatting.

Reviewed changes

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

File	Description
Library/Homebrew/livecheck/skip_conditions.rb	Joins multiple messages and prints the combined output.
Library/Homebrew/test/livecheck/skip_conditions_spec.rb	Adds tests asserting multi-message output is printed correctly.
Library/Homebrew/tests/parallel_runtime_rspec.log	Adds a runtime log artifact (appears unrelated to functional changes).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[samford]

As the author of this code, I considered joining multiple messages (albeit, using a semicolon because messages may contain a comma) but I decided to leave it unimplemented until there was a demonstrated need. This wasn't a firm TODO but more of a reminder for myself that this is a limitation of the current approach, so I should have used NOTE instead.

Could you provide an example from a formula or cask where there's more than one skip message and the existing approach isn't sufficient?

[rexmhall09]

@samford

Thanks for your comment!

I am unaware of a current formula or cask producing multiple skip messages, but messages is already modeled as an array in the skip hash. Joining them helps future-proof the behavior so it won’t need to be revisited if multiple messages are returned later.

I definitely see the argument for a semicolon as the delimiter, I used a comma as that was the first thing I thought of.

Honestly, I mainly noticed the TODO comment about multiple messages and figured implementing it would be a small improvement.

[samford]

Looking through the SkipConditions methods, I'm remembering that none of them provide more than one message (it's either one or none). I originally chose to use an array for messages (rather than a string) in case we ever needed to have more than one message but it hasn't been necessary in the five years since then. [I probably should have started with a string and only changed it to an array when it became necessary.]

I was waiting for a skip method to provide more than one message before implementing this but we already use [:messages].join in brew bump, so there's no harm in doing the same in print_skip_information.

---

Please make the following changes:

• The test cases have been placed in the "when a formula has a livecheck block containing skip" context but it's not possible to have multiple messages from a skip call in a livecheck block. These test cases should be placed in a separate context after this one (e.g., context "when a formula produces multiple messages").
• In existing tests, we store the arguments in status_hashes, so the new tests should use the same approach. You can place the new hashes after the existing skip_with_message hashes.
• Let's use generic "First message" and "Second message" strings (and "First error" and "Second error" for the error strings), as this is currently a hypothetical scenario and there aren't defined strings to use in this context. This will limit unnecessary detail that could confuse readers into thinking that we're testing something specific.

This will need to be duplicated for casks (i.e., skip and error hashes in status_hashes[:cask] and a context "when a cask produces multiple messages" block [with similar tests] placed after the existing "when the cask has a livecheck block containing skip" context).

[MikeMcQuaid]

Thanks!