Allow specifying secrets in app resource

[lukas-w]

Adds a secret option to the fly_app resource and some basic tests. This also updates terraform-plugin-framework to 0.14 and does some minor refactoring. Commits are probably best reviewed one by one.

Disregard, fixed via https://community.fly.io/t/overriding-staged-secrets-for-machines/8493/5:

One test check is failing because it appears that in some situations the `SetSecrets` API call has no effect despite not returning any error, especially when called with a value that has been used before. Something must be wrong server-side. The resource can't reliably detect this because the digest algorithm is not disclosed as far as I can see.

There are several reports in the forums that may be related to this:

• https://community.fly.io/t/overriding-staged-secrets-for-machines/8493
• https://community.fly.io/t/flyctl-secrets-unset-does-nothing/8334
• https://community.fly.io/t/setting-secrets-before-the-first-deployment-does-nothing/5589

The first link contains steps to reproduce. My code may be buggy too of course, but I find it hard to test while the API itself is behaving erratically

Usage:

resource "fly_app" "my_app" {
  name = "my_app"
  secrets {
    SECRET_PASSWORD = {
      value = "top-secret-value"
    }
  }
}

Resolves #27

[DAlperin]

This is awesome, I will take a look at this later today.

[lukas-w]

Pushed af3baa0 which fixes a bug that would have caused loss of unmanaged secrets. The way this works currently is that the resource doesn't touch any secrets that haven't been specified in config, so as not to overwrite or delete secrets that have been set outside of Terraform such as DATABASE_URL via flyctl pg attach.

[freeatnet]

@DAlperin is there any chance this could be released?

[bosc0]

I have been looking forward to this feature for a while as well, thanks for the PR! Nit: it would be more consistent for secrets to follow the same notation as env vars in machines https://registry.terraform.io/providers/fly-apps/fly/latest/docs/resources/machine#env which would be something like this:

resource "fly_app" "my_app" {
  name = "my_app"
  secrets = {
    key = "value"
  }
}

Also it is unclear to me how app secrets would interact with machine env vars (or even machine secrets; is that a thing?). I assume machine env vars would override an app secret with the same key, in which case it probably makes sense to allow machine specific secrets as well.

[lukas-w]

it would be more consistent for secrets to follow the same notation as env vars

Albeit more concise, my reasoning for not doing this is that it seemed the most natural way to also provide the secret's digest and timestamp via fly_app.my_app.secrets.key.digest and fly_app.my_app.secrets.key.created_at respectively.

[DAlperin]

I'm gonna take some time to go through some PRs and issues this week or next week. I work at fly.io proper now, I did not when I started this. That along with life has made things a bit hectic for me :) I appreciate all of you for chiming in on this PR. I'll give it a proper review soon.

[fenos]

@DAlperin any update? 🙏

[OJFord]

It would be better as a separate fly_secret resource IMO - consistent with how they're shown in the web console, and helps avoid cycles.

For example I have one (an API token) that's derived from the fly_ip (to limit from where it can be used) which of course depends on fly_app.

With the provider built from this PR (thanks!) I thus get an error when it detects that cycle.

[lukas-w]

It would be better as a separate fly_secret resource IMO - consistent with how they're shown in the web console, and helps avoid cycles.

That's what I did first but it makes non-machine apps hardly usable because Fly's API triggers a new deployment for each setSecrets call (#27 (comment) for reference).

[OJFord]

Aren't non-machine ('v1') apps deprecated anyway? I didn't think it was even possible to create them with this provider (I tried it first - the app just sat there waiting for a machine.)

[damianstasik]

I just tested this change and I really appreciate the work you put into this PR @lukas-w! One thing I stumbled upon during the test is removing secrets. I tried swapping one secret with another and after the changes were applied new key was added, but the old was not removed. Is this expected?

[floydspace]

Thank you @lukas-w , it works like a charm for my case, I published the fork provider with all the PRs opened in this repo. Seems like maintenance of the provider was abandoned for some time

[floydspace]

I just tested this change and I really appreciate the work you put into this PR @lukas-w! One thing I stumbled upon during the test is removing secrets. I tried swapping one secret with another and after the changes were applied new key was added, but the old was not removed. Is this expected?

@damianstasik gonna check it as well

[ebenoist]

I would love to see this released! It would be a huge benefit for environments where there are multiple people adjusting secrets.

Anything I can help with to get this across the line?

[bxb100]

It takes a long time to test, any update here?

[zxaos]

Closed due to history re-write, but refiled as #192