@tkuah Just to be clear I'm guessing that you're suggesting the master key credentials are committed to the repo as a workaround, right?
I just want to be clear because I'm not fully sure how the above solution works.
As well I'd like to ensure that we are very careful if we are suggesting people commit secret keys to repos because we want to have our documentation only ever suggests secure by default principles or at the very least note that you must only use this for private projects as otherwise anyone can read the credentials.
@tkuah Just to be clear I'm guessing that you're suggesting the master key credentials are committed to the repo as a workaround, right?
Oh no ! It's more that there's no way to recover the contents of the checked in encrypted credentials, so it's more a way to re-generate a new config/credentials.yml.enc file.
It's more that there's no way to recover the contents of the checked in encrypted credentials
Well we should also be clear that even if there was a way it would be a very bad idea because then everybody would have the same secret keys. So best practice is to generate unique secret keys.
Actually I have a bigger product concern here which is that we're encouraging users to use a rails template repo from GitLab rather than encouraging users to run rails new which is the rails recommendation. This introduces at the very least some security problems described in this issue but it may be even worse because we don't have up to date gems etc. if we're doing this. Just a thought but I'd rather just document how to set things up the rails way (ie. with rails new) than have a rails template that we're constantly maintaining and even then we still need some way to tell the users to edit all the secrets in the repo before deploying anyway so the template doesn't have all that much use and we're constantly working on keeping it maintained.
@bikebilly or @ayufan maybe you have some historical perspective here about why we're using templates but at this point I'm wondering if there is a better way because it is a maintenance problem for Auto DevOps compatibility.
maybe you have some historical perspective here about why we're using templates but at this point I'm wondering if there is a better way because it is a maintenance problem for Auto DevOps compatibility.
We had existing import functionality that was part of the stack, we did know that it does not allow to execute dynamic commands at that moment.
Actually I have a bigger product concern here which is that we're encouraging users to use a rails template repo from GitLab rather than encouraging users to run rails new which is the rails recommendation.
I agree with this, creating projects this way is not the "Rails Way".