Seems to be some issues with secrets at the moment. Unless it is just me.
e.g for an example:
$ flyctl --app name secrets set AWS_DEFAULT_REGION="eu-west-2"
Error no change detected in secrets
$ flyctl --app name secrets set AWS_DEFAULT_REGION="madeup"
Error no change detected in secrets
$ flyctl --app name secrets set AWS_DEFAULT_REGION="hmm"
Error An unknown error occured.
… it doesn’t seem to spot changes in secrets. Unsetting a secret leaves it set too. Hmm.
It would really help if the console had some UI way to set/remove secrets. Manually typing them in the CLI in huge commands isn’t ideal.
$ flyctl --app name secrets set AWS_DEFAULT_REGION="this-value-is-different"
Error no change detected in secrets
$ flyctl --app name secrets set AWS_DEFAULT_REGION="and-this-value-is-different"
Error no change detected in secrets
To confuse things, when I list the secrets, it seems to have spotted the change. I don’t know the value it now thinks it is because it just shows a digest, naturally. So I guess I would have to add some kind of debug line in the app to get it to output to console/logs and wait for them to come in.
However … if the value had changed … it should trigger a new deployment, I would think. Which it hasn’t. So not sure what is happening.
$ flyctl --app name secrets list
NAME DIGEST DATE
AWS_DEFAULT_REGION 500e3c268d448f7036ab9a0d3b... 8s ago
I tried it again, and sure enough, got 'no change detected in secrets.
But when I listed the secrets, the digest had changed. So it has realised there is a new value.
But not triggered a deployment. Does that only happen if a secret is added/removed? In which case perhaps that is correct behaviour. Apart from the error message.
… although … if the value of the secret gets ‘baked in’ to the instance when it is deployed, that would not be correct behaviour. As it would be left with the old value of the secret. Hmm.
On the other hand, if the value of the secret is read-in at runtime, then a changed value would not require a new deployment. Not sure how things work at your end, naturally, what the expected flow is. So far I’ve seen a new deployment happen each time but maybe that was just because of the sequence happened to add/remove a secret.
Yes, it is showing a release there. So it is deploying by the looks of that. Just in the background, presumably. So I guess the error message is disconnecting from the deployment process. Since previously when I changed a secret, I saw a message saying deploying a new version and it does its thing and lists the instance, healthy etc. That must be happening but just in the background by the looks of the releases page as it does take about two minutes to release which would match the timings.
So maybe that error isn’t so much of an issue if it actually is detecting a change in the value (based on the digest) and is triggering a deploy (based on releases) after all.
It may be connected to this, but on the ‘secrets list’ page, the DATE column does not show the time a few seconds ago for that secret.
But that may be correct. I’m not sure if the “DATE” column is showing the time the secret was created or the time it was last modified. If it was the time it was created, that is correct. If it is the time it was last modified, it’s wrong. Since it should be showing the date today if so.
Is it possible you reset that secret the value it was on Sept 8th? We version secrets internally, if you set a value you’ve used before it just uses the older version. It’s not well exposed through our CLI though.
You are right. I hadn’t realised that was the case. Yep, I have been cycling through AWS regions today trying eu-west-1,2,3 … is there even a 3? Don’t know. Anyway, yep, if I set it as eu-west-2, the date drops back to September. If I try eu-west-3, which I’ve never typed before, sure enough the DATE changes to 5s ago. So it is essentially time that value was first seen.
That explains that.
I still get Error no change detected in secrets
But that doesn’t matter if it’s doing the right things behind the scenes
