Issue archiving base64 encoded content w/ source block

[lineardraft]

Terraform CLI and Provider Versions

Terraform v1.2.3
on darwin_amd64

• provider registry.terraform.io/hashicorp/archive v2.2.0

Terraform Configuration

data "archive_file" "input_archive" {
  type        = "zip"
  source_file = "${path.module}/input.file"
  output_path = "${path.module}/files/input.zip"
}

data "archive_file" "output_archive" {
  type        = "zip"
  output_path = "${path.module}/files/output.zip"

  source {
    content = filebase64(data.archive_file.input_archive.output_path)
    filename = "${data.archive_file.input_archive.output_path}"
  }
}

Expected Behavior

Just for the sake of producing an working bug in the Terraform configuration we have the following:

1. First "archive_file" creates a dummy archive 'input.zip' based on 'input.file'
2. Second "archive_file" creates an 'output.zip' w/ base64 contents of 'input.zip' archive (since it's a binary file using filebase64 function)

Expected behaviour is that the input.zip archive that is archived within output.zip archive is valid and extractable.

Actual Behavior

When 'output.zip' archive is extracted, 'input.zip' is present but it's not extractable. Upon closer inspection it seems that it's still base64 encoded.

Steps to Reproduce

1. terraform apply

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[lineardraft]

Hello, is anybody at least going to acknowledge this issue?

[kjschiroo]

I stumbled across this problem and I think the ultimate answer is that it is doing what it is supposed to and this use case just isn't supported.

I'd come across this when I was trying to create a zip containing a binary executable for deployment to an AWS lambda layer. I needed the binary to be within a specific location in the zip (bin/my_binary). As I understand it the only way to control the location within the resulting zip is to use the source sub-block. However the source sub-block requires source.contents which it expects to be a string representing the literal contents of your file. As you discovered with your zip and I with my executable those bits don't string, so we b64 encode them because that's what terraform points us towards, but that changes the actual contents of the file to the b64 encoding (not the raw bytes we needed).

My beautiful imagined world would have something like

data "archive_file" "output_archive" {
  type        = "zip"
  output_path = "${path.module}/output.zip"
  
  source {
    // Dear TL;DRers, this isn't a real param, just a suggestion.
    source_path = "${path.module}/my_raw_binary"
    filename = "${data.archive_file.input_archive.output_path}"
  }
}

So sadly I think the solution is to make the zip outside of terraform. 😞

[emoshaya]

we need content_base64 argument similar to the local_file resource here:

https://registry.terraform.io/providers/hashicorp/local/latest/docs/resources/file#content_base64

[goshander]

Its very simple and basic functionality and is still not implemented 😞

[jkstpierre]

Just stumbled upon this issue myself. The source block needs to have a content_base64 argument implemented ASAP

[rdavisunr]

Another vote for this functionality. Seems like a big oversight that it's still MIA.