Add new opt-in flag to specify the output_file_mode to produce more deterministic behavior across operating systems.

[virgofx]

This adds new functionality to address the deterministic behavior via an additional opt-in parameter. This is non-breaking with respect to existing functionality; however, should be helpful in that it will reduce the numerous issues resolving non-deterministic behavior for those that build cross platform by allowing them to set file output mode.

✔️ Tests included
✔️ Documentation updated

Fixes via Workaround for:

• archive_file changes file permissions #10
• archive_file produces different results on different OSs #34
• Force file mode inside archive #53
• archive_file changes file permissions on Windows #58
• Ability to set explicit permissions on files included in archives #59

Other References:

• Consistently set archived file permissions #41
• added 'mode' argument #80

Would love to get this reviewed and hopefully merged.

/cc: @appilon @kmoe @mbfrahry @EamonHetherton @Supermathie @maxrothman @timwsuqld @nathanielks @karolkania @xarses @sapher @quixand @olfway @bee-keeper

[hashicorp-cla]

All committers have signed the CLA.

[64kramsystem]

This may work for a significant part of the cases, but not all. #34 is a wider issue, which includes different O/S libraries producing different compressed streams.

Please not CC me, I don't want to have anything to do with this project.

Edit: Comment edited to remove language that doesn’t abide by our code of conduct.

[virgofx]

Definitely share your frustration with the lack of attention to this issue, which is why I spent a day to come up with a better opt-in approach to at least solve this without having to maintain a fork (which I did not want to do). I still think this issue would resolve the umask/permissions issues described in #34 by directly specifying the permissions. I don't see the changes here as breaking in anyway so I'm hoping the maintainers would at least compromise and include this work around.

[64kramsystem]

Definitely share your frustration with the lack of attention to this issue, which is why I spent a day to come up with a better opt-in approach to at least solve this without having to maintain a fork (which I did not want to do). I still think this issue would resolve the umask/permissions issues described in #34 by directly specifying the permissions. I don't see the changes here as breaking in anyway so I'm hoping the maintainers would at least compromise and include this work around.

Ah, I think I've been ambiguos - didn't meant to diminish this work :) I think like you, that any work that goes upstream, is definitely an improvement of the status quo! 😄 Good luck 😬

[virgofx]

@kmoe @appilon Any chance you could review? Thanks

[aareet]

Thank you for your patience. As a small team, we do our best to address issues in order of priority. Since this is an issue we have previously engaged on, it is of higher priority in our backlog. We will take a look soon.

[kmoe]

Thank you for this PR, @virgofx. I believe this provides a reasonable way for most users to ensure deterministic zip creation across OSs.

I've added some acceptance tests in #92 to demonstrate the fix, using the fact that our CI builds run across Ubuntu, macOS, and Windows. Please cherry-pick 4246a0c and 4ddf87a (squashed together if you like) onto your branch. We now check the exact value of the hashes, which I think is fine, as we want to know if the bytes of the zip change for any other reason anyway.

I'm going to request that users experiencing #34 test whether the archive_file_mode workaround enabled by this PR works for them.

[virgofx]

Thanks for the feedback @kmoe! The PR is updated with acceptance tests and t.Helper() on helper functions as mentioned in your review.

I've provided zipped up-to-date binaries for primary platforms from this branch for anyone who is interested in testing:

• terraform-provider-archive-windows-amd64.zip
  sha256:04a9f96f0dc947fcb8ae65ffc35578cef7bdbd4464d9bda0ff3aa9c4a55e1ec5
• terraform-provider-archive-linux-amd64.zip
  sha256:3782f7a641ce7b53b0a125de786b0f7ce7fe68d26ffab0005e7848083345681a
• terraform-provider-archive-darwin-amd64.zip
  sha256:473c0740d36a8be6bbcedded34ba023c9a0e82f600326506aca945ac0553e89a

[kmoe]

Thanks, @virgofx - looks good. This will be released today in v2.2.0.

[virgofx]

Thanks @kmoe. Maybe we should do some spring cleanup on the referenced issues making a note to this PR and then close accordingly? I feel this provider is fairly stable and it would allow more attention to other open PRs.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.