Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing: Test Create Block with more OS and Node versions #38368

Merged
merged 6 commits into from
Feb 2, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 8 additions & 3 deletions .github/workflows/create-block.yml
Original file line number Diff line number Diff line change
Expand Up @@ -15,12 +15,16 @@ concurrency:
jobs:
checks:
name: Checks
runs-on: ubuntu-latest
runs-on: ${{ matrix.os }}
if: ${{ github.repository == 'WordPress/gutenberg' || github.event_name == 'pull_request' }}
strategy:
fail-fast: false
matrix:
node: ['12', '14']
node: [14]
os: [macos-latest, ubuntu-latest, windows-latest]
include:
- node: 12
os: ubuntu-latest

steps:
- uses: actions/checkout@5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f # v2.3.4
Expand All @@ -32,6 +36,7 @@ jobs:
cache: npm

- name: npm install, build, format and lint
shell: bash
run: |
npm ci
npm run test:create-block
sh ./bin/test-create-block.sh
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless there is a GitHub Actions quirk that I am not aware of, in a normal environment this invocation is problematic, because test-create-block.sh isn't a POSIX shell script, but a Bash script with specific Bashisms. So it should be:

bash ./bin/test-create-block.sh

I'll open a follow-up PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(FWIW, we're setting the shell to bash, so in practice, it shouldn't matter much IIUC.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(FWIW, we're setting the shell to bash, so in practice, it shouldn't matter much IIUC.)

Indeed, but I don't understand what that actually means, mechanically. :) That is, in the end in the runtime there must be something equivalent to exec, and this could either mean that some layer is honouring the hashbang (parsing the first line of the script — #!/bin/bash — and thus exec'ing /bin/bash with the script path as argument), or that some layer is directly exec'ing entire string in the config — bash ./bin/test-create-block.sh. I have no idea what kind of effect shell: bash plays in the middle of this!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, coming back to this from another angle: Are there even that many Bashisms left? Seems like -ne could be actually POSIX-compliant 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the -ne is fine and dates back to the original Unix days, I believe. :) According to ShellCheck, the only Bashism is the -e flag passed to echo. Replacing echo -e with printf should be enough — just don't forget the trailing newline.

Btw, ShellCheck is available as a linter. I have it in Vim, so I'm sure it's trivial to install in VSCode. I highly recommend it. It not only prevents mistakes, but it has also taught me a lot thanks to the detailed explanations in the wiki. :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the reminder! I was still copying code back and forth into shellcheck.net. (I have yet to try if it's clever enough to work inside of the workflow YAML 🤔 )

12 changes: 12 additions & 0 deletions bin/test-create-block.sh
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,10 @@ status () {
echo -e "\n\033[1;34m$1\033[0m\n"
}

error () {
echo -e "\n\033[1;31m$1\033[0m\n"
}

cleanup() {
rm -rf "$DIRECTORY/esnext-test"
}
Expand All @@ -31,6 +35,14 @@ status "Formatting files..."
status "Building block..."
../node_modules/.bin/wp-scripts build

status "Verifying build..."
expected=5
actual=$( ls build | wc -l | awk '{$1=$1};1' )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

awk '{$1=$1};1'

Mysterious incantation! 😄

OK, I think I got it: is the issue that, because wc -l formats the output with a leading space, the comparison [ "$expected" != "$actual" ] always fails? There are a couple of ways to make this clearer:

  • Since we're already invoking AWK, we can let it do the counting too: awk 'END { print NR }', which means "once the end of the file/stream is reached, print the number of records, i.e. lines, that we have processed. Alternatively, grepcan also count:grep -c .` (the dot represents any character to match)
  • But, actually, Bash is capable of arithmetic comparison: [ "$expected" -ne "$actual" ], where -ne stands for "not equal". In this scenario, Bash will parse the numbers unencumbered by formatting.

if [ "$expected" != "$actual" ]; then
error "Expected $expected files in the build folder, but found $actual."
exit 1
fi

status "Lintig CSS files..."
../node_modules/.bin/wp-scripts lint-style

Expand Down