Closed oliveirafilipe closed 6 years ago
Thanks for your interest into this!
I guess this behaviour is kind of "historical grown". I designed this for a production environment. I'm not even sure if there was a Staging-option at certbot.
Therefore the default behaviour was "production". By defining the "STAGING"-option on this image - and making it optional - the default behaviour was saved.
Any change in this behaviour will be a breaking change in the usage of this image. If there is a good reason doing this I will do it. But there should be a good reason for defining a next API-version....
I agree that any "Docker run"-examples should be expanded with the STAGING-option and the "Docker run"-command for production should be mentioned exiplicitely. By doing that the probability of running into this problem could reduced.
Hi @BirgerK , your image is being so usefull, despite i'm not using your config scripts because of this logic of PRODUCTION
/ STAGING
:(
As you said:
Any change in this behaviour will be a breaking change in the usage of this image. So i will close this issue. But I will continue to use, review and help it in the possible. Tks
This is a discussion that could be a refact.
I'm using this docker image and so far so good, but there is on logic that I think that is weird.
To issue Staging Certs, you need to set up the flag
STAGING
but most of the time you're developing, you're actually needing theSTAGING
.So I propose to invert the logic, using the flag
PRODUCTION
. So when you need production certificates you define the flag. This prevents undesired generation of valid certificates if you forget the tag.