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

Force file mode inside archive #53

Closed
Supermathie opened this issue Oct 31, 2019 · 4 comments
Closed

Force file mode inside archive #53

Supermathie opened this issue Oct 31, 2019 · 4 comments

Comments

@Supermathie
Copy link

Supermathie commented Oct 31, 2019

We've discovered that the file mode of source files is now preserved by archive_file. While we recognize everybody has different requirements, we think it would be useful to be able to specify a mode for files either for the entire archive or for a single source.

Especially given how often this seems to rear its head. Would you welcome a PR on this?

Terraform Version

Terraform v0.12.12

  • provider.archive v1.3.0
  • provider.aws v2.34.0
  • provider.external v1.2.0
  • provider.random v2.2.1
  • provider.template v2.1.2

Affected Resource(s)

Please list the resources as a list, for example:

  • archive_file

Terraform Configuration Files

data "archive_file" "snapshot_replica" {
  type        = "zip"
  source_file = "${path.module}/snapshot-replica-lambda/index.js"
  output_path = "${path.module}/snapshot-replica-lambda/snapshot-replica-lambda.zip"
}

Debug Output

(can provide)

Expected Behavior

The sha256sum of the generated zipfile is consistent across machines. This seems to be the expectation implied by #10.

Actual Behavior

The sha256sum of the generated zipfile differs depending on the mode of the source file in the archive.

Steps to Reproduce

  1. On Computer A, index.js has the mode 0644 (it has a umask of 0022)
  2. On Computer B, index.js has the mode 0664 (it has a umask of 0002)
  3. tf plan on both machines
  4. The generated archive differs as follows:
○ → zipinfo kronos-snapshot-replica-lambda.zip 
Archive:  kronos-snapshot-replica-lambda.zip
Zip file size: 815 bytes, number of entries: 1
-rw-r--r--  2.0 unx     1951 bl defN 49-Jan-01 00:00 index.js
1 file, 1951 bytes uncompressed, 685 bytes compressed:  64.9%

○ → zipinfo challenger-snapshot-replica-lambda.zip 
Archive:  challenger-snapshot-replica-lambda.zip
Zip file size: 815 bytes, number of entries: 1
-rw-rw-r--  2.0 unx     1951 bl defN 49-Jan-01 00:00 index.js
1 file, 1951 bytes uncompressed, 685 bytes compressed:  64.9%
@appilon
Copy link
Contributor

appilon commented May 12, 2020

Hello @Supermathie our apologies for not responding sooner. It appears this issue, #10 #58 #34 are all related. It appears the permissions being misset across operating systems is problematic for a number of reasons, but a popular one being #34 . Yes we would be willing accept a PR enhancing the provider with the ability to force file mode within the archive. There have been similar attempts in #41 and #47.

We would certainly review a pull request with this enhancement, but understand you may have moved on or simply don't have the spare time. Regardless if a community member manages to submit a PR or not, we will try and have this option implemented. Thank you for your contributions to the Terraform Ecosystem.

@riking
Copy link

riking commented Oct 25, 2020

Note: We now correct the permissions in the wrapper Makefile.

@kmoe
Copy link
Member

kmoe commented May 5, 2021

The workaround in #90 has been released in terraform-provider-archive v2.2.0. If output_file_mode does not solve your problem, please comment on this issue or open a new one.

Copy link

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

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants