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

Add @go.create_gzipped_tarball and perform other small refactors #211

Merged
merged 8 commits into from
Sep 10, 2017

Conversation

mbland
Copy link
Owner

@mbland mbland commented Sep 10, 2017

Closes #186. Normally I would split these into separate PRs, but in the interest of putting #186 to bed and moving on, I'm eliding them here.

@go.canonicalize_path now accepts --pwd and --parent <dir> options for convenience, rather than forcing the caller to use @go.add_parent_dir_if_relative_path directly.

@go.mirror_directory now mirrors the entire source directory by default.

@go.create_gzipped_tarball throws in tons of sanity checks and provides maximum portability, when a handful of direct commands just won't do. (The same could be said for @go.mirror_directory.)

create_fake_tarball_if_not_using_real_url now uses @go.mirror_directory, but not @go.create_gzipped_tarball, since the latter follows the convention that the extracted directory matches the basename of the tarball. With GitHub releases, the name of the extracted directory does not match the basename of the tarball, e.g. v1.6.0.tar.gz extracts to go-script-bash-v1.6.0. So in this case, it was easier to use @go.mirror_directory, then use tar directly, despite the fact that create_fake_tarball_if_not_using_real_url inspired @go.create_gzipped_tarball, which then inspired @go.mirror_directory.

(If @go.create_gzipped_tarball doesn't prove useful in the long run, I can remove it in v2.0.0.)

Finally, after digging deeper into process substitution vs. pipes during the implementation of @go.mirror_directory from lib/fileutil, I realized a few things:

  • The same number of processes are spawned.
  • There's little benefit to a process substitution for straightforward pipes when the output isn't consumed by the shell process.
  • It's not straightforward to get the status from a process substitution, and neither '$!' nor wait help.
  • The 'PIPESTATUS' variable is available to check the status of each process in the pipe, without the need for set -o pipefail.

Hence, go-template now uses a {curl,fetch,cat,wget} | tar pipe with a [[ ${PIPESTATUS[0]} -ne '0' ]] check. There's a new test case for tar failure, and the 'fail to download ...' test cases required a little tweaking to ensure they properly cover the cases where ${download_cmd[@]} fails.

(Yeah, really shoulda been separate PRs.)

Since I found myself calling `@go.add_parent_dir_if_relative_path`
before `@go.canonicalize_path` quite frequently, I figured it made sense
to add these flags to elide the two calls into one.
As I discovered implementing the upcoming `@go.create_gzipped_tarball`,
this makes for a more natural interface.

Also fixes a bug whereby I'd used `set "$BATS_DISABLE_SHELL_OPTIONS"` in
the tests, when it should've been `set "$DISABLE_BATS_SHELL_OPTIONS"`.
Part of #186. Throws in the kitchen sink when it comes to sanity checks
and portability.
Uses `@go.mirror_directory` from `lib/fileutil`. Also extracted an
implementation helper for a slight performance boost.
After digging deeper into process substitution vs. pipes during the
implementation of `@go.mirror_directory` from `lib/fileutil`, I
realized a few things:

* The same number of processes are spawned.
* There's little benefit to a process substitution for straightforward
  pipes when the output isn't consumed by the shell process.
* It's not straightforward to get the status from a process
  substitution, and neither '$!' nor `wait` help.
* The 'PIPESTATUS' variable is available to check the status of each
  process in the pipe, without the need for `set -o pipefail`.

Also adds a test case for `tar` failure. The 'fail to download ...' test
cases required a little tweaking to ensure they properly cover the cases
where `${download_cmd[@]}` fails.
The tests are more focused without these assertions, especially
`assert_go_core_unpacked`.
Forgot to ensure the assertions contained `$NATIVE_LOCAL_URL`, since I'm
forcing the test case to use the locally-generated tarball.
@coveralls
Copy link

Coverage Status

Coverage increased (+0.07%) to 95.145% when pulling 41daa0c on tarball-#186 into 2f731d6 on master.

The 'fail to download ...' test cases failed on MSYS2, since those cases
use a local download URL. Applying `@go.native_file_path_or_url` to the
URL before making the assertions fixes the problem.
@coveralls
Copy link

Coverage Status

Coverage increased (+0.07%) to 95.145% when pulling d60a272 on tarball-#186 into 2f731d6 on master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.07%) to 95.145% when pulling e885b4a on tarball-#186 into 2f731d6 on master.

@mbland mbland merged commit 98bb9ba into master Sep 10, 2017
@mbland mbland deleted the tarball-#186 branch September 10, 2017 21:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants