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

Tests rely on brittle umask behavior #99

Closed
robdimsdale opened this issue Aug 6, 2022 · 1 comment
Closed

Tests rely on brittle umask behavior #99

robdimsdale opened this issue Aug 6, 2022 · 1 comment

Comments

@robdimsdale
Copy link
Member

Expected Behavior

Tests pass out of the box irrespective of umask value.

Current Behavior

I cloned jam and ran the tests, and I observed that some tests fail. Specifically, there are some tests (e.g. this one) that assume the local umask is set to 0022. My default umask was set to 0002, so when I cloned the repo the files were created with permissions: 0775 instead of the assumed 0755.

Possible Solution

There are two possible ways to fix this, depending on whether jam should preserve the original permissions of the files being bundled:

  • Update the tests to verify the bundled permissions are the same as the original file permissions. Do this if we don't particularly care what the file permissions of the bundled files are.

OR

  • Explicitly write the desired permissions when bundling the file (similar to this). Do this if we want to be sure that the bundled files have known permissions.

Steps to Reproduce

Run the following commands

  1. umask = 0022
  2. git clone https://github.com/paketo-buildpacks/jam /tmp/jam
  3. cd /tmp/jam
  4. go test -v ./internal/...

Observe test failures e.g.:

=== RUN   TestUnitInternal/jam/internal/FileBundler/Bundle/returns_a_list_of_cargo_files
    file_bundler_test.go:53:
        Expected
            <fs.FileMode>: 509
        to equal
            <fs.FileMode>: 493

Motivations

I am trying to run the jam tests locally and it is inconvenient to have to temporarily change my umask before cloning (or manually update the permissions of all relevant files after cloning).

@robdimsdale
Copy link
Member Author

I'm going to close this issue. There have been no other reports of umask-related test failures since I created this issue. It might be that my machine was set up in an unusually-restricted state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant