Can the output of `bundle check` be un-hidden?

[bewuethr]

I noticed a warning popping up in some of my builds recently:

Warning:  github-pages can't satisfy your Gemfile's dependencies.

Example: this workflow.

It seems that this is due to the change in #61, but I was a bit stumped which dependency this would be – my Gemfile is just this:

source "https://rubygems.org"

ruby "2.7.4"

gem "github-pages", "~> 228", group: :jekyll_plugins

As it turns out, the warning is due to a version mismatch in Gemfile.lock, but because the output is thrown away (>/dev/null 2>&1) here

jekyll-build-pages/entrypoint.sh

Line 17 in 98742cd

if test -e "$SOURCE_DIRECTORY/Gemfile" && ! bundle check --dry-run --gemfile "$SOURCE_DIRECTORY/Gemfile" >/dev/null 2>&1; then

I had to figure out with trial and error.

Would it make sense to not hide that output, to make figuring this out a little easier? For what it's worth, my Gemfile.lock is the result of bundle install on that minimal Gemfile, and when I run bundle check with the Gemfile provided by this action with my Gemfile.lock in the container provided by this action, I get

$ bundle check --dry-run --gemfile Gemfile
Resolving dependencies...
The following gems are missing
 * nokogiri (1.14.1)
Install missing gems with `bundle install`

which I assume is because the Dockerfile uses

jekyll-build-pages/Dockerfile

Line 13 in 98742cd

RUN NOKOGIRI_USE_SYSTEM_LIBRARIES=true bundle install

and having the action output include the missing gem would have made figuring this out way easier.

tl;dr, I suggest

@@ -14,7 +14,7 @@
 GITHUB_PAGES=$PAGES_GEM_HOME/bin/github-pages
 
 # Check if Gemfile's dependencies are satisfied or print a warning 
-if test -e "$SOURCE_DIRECTORY/Gemfile" && ! bundle check --dry-run --gemfile "$SOURCE_DIRECTORY/Gemfile" >/dev/null 2>&1; then
+if test -e "$SOURCE_DIRECTORY/Gemfile" && ! bundle check --dry-run --gemfile "$SOURCE_DIRECTORY/Gemfile"; then
   echo "::warning:: github-pages can't satisfy your Gemfile's dependencies."
 fi

because showing the output is helpful. Would such a PR be welcome?

[dijonkitchen]

Might be faster to make the PR than ask? I'd do it, but you deserve the git praise!

[emiliebarnard]

I am running into the same issue.

[bewuethr]

Woohoo 🥳

[JamesMGreene]

This is now released in v1.0.8 and the latest v1. 🚀