fix: lint scripts for local and CI (#961)

.github/workflows/lint.yml

@@ -17,17 +17,7 @@ jobs:
         uses: asdf-vm/actions/install@v1
 
       - name: Run ShellCheck
-        run: |
+        run: scripts/shellcheck.bash
-          shellcheck -s bash -x \
-            asdf.sh \
-            release/tag.sh \
-            bin/asdf \
-            bin/private/asdf-exec \
-            lib/utils.bash \
-            lib/commands/*.bash \
-            completions/*.bash \
-            test/test_helpers.bash \
-            test/fixtures/dummy_plugin/bin/*
 
   shellfmt:
     runs-on: ubuntu-latest
@@ -42,4 +32,4 @@ jobs:
         run: shfmt -f .
 
       - name: Run shfmt
-        run: shfmt -d .
+        run: scripts/shfmt.bash

release/README.md

@@ -1,19 +1,29 @@
 # Release README
 
-If you are a user you can ignore everything in this directory. This directory contains documentation and scripts for preparing and tagging new versions of asdf and is only used by asdf maintainers.
+If you are a user you can ignore everything in this directory. This directory
+contains documentation and scripts for preparing and tagging new versions of
+asdf and is only used by asdf maintainers.
 
 ## Tagging Release Candidates
 
 To tag release candidates
 
-1. Update the CHANGELOG. Make sure it contains an entry for the version you are tagging as well as a dev version things that come after the tag (e.g. a heading with the format `<next-version>-dev`)
+1. Update the CHANGELOG. Make sure it contains an entry for the version you are
-2. Run the tests and the linter - `bats test`
+   tagging as well as a dev version things that come after the tag (e.g. a heading
-3. Run the release script. The new version must be in the format `0.0.0-rc0`. For example: `release/tag.sh 0.0.0-rc0`
+   with the format `<next-version>-dev`).
-4. If the release script succeeds, push to GitHub. Make sure to use the correct remote to push to the official repository
+2. Run the tests, linter and format check - `bats test`, `./scripts/shellcheck.bash` and `./scripts/shfmt.bash`.
+3. Run the release script. The new version must be in the format `0.0.0-rc0`.
+   For example: `release/tag.sh 0.0.0-rc0`.
+4. If the release script succeeds, push to GitHub. Make sure to use the correct
+   remote to push to the official repository
 
 ## Tagging Releases
 
-1. Update the CHANGELOG. Make sure it contains an entry for the version you are tagging as well as a dev version things that come after the tag (e.g. a heading with the format `<next-version>-dev`)
+1. Update the CHANGELOG. Make sure it contains an entry for the version you are
-2. Run the tests and the linter - `bats test`
+   tagging as well as a dev version things that come after the tag (e.g. a heading
-3. Run the release script. The new version must be in the format `0.0.0`. For example: `release/tag.sh 0.0.0`
+   with the format `<next-version>-dev`).
-4. If the release script succeeds, push to GitHub. Make sure to use the correct remote to push to the official repository
+2. Run the tests, linter and format check - `bats test`, `./scripts/shellcheck.bash` and `./scripts/shfmt.bash`.
+3. Run the release script. The new version must be in the format `0.0.0`. For
+   example: `release/tag.sh 0.0.0`.
+4. If the release script succeeds, push to GitHub. Make sure to use the correct
+   remote to push to the official repository

scripts/shellcheck.bash

@@ -0,0 +1,13 @@
+#!/usr/bin/env bash
+
+exec shellcheck -s bash -x \
+  asdf.sh \
+  completions/*.bash \
+  bin/asdf \
+  bin/private/asdf-exec \
+  lib/utils.bash \
+  lib/commands/*.bash \
+  release/tag.sh \
+  scripts/*.bash \
+  test/test_helpers.bash \
+  test/fixtures/dummy_plugin/bin/*

scripts/shfmt.bash

@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+
+exec shfmt -d .