Closed loispostula closed 2 months ago
@loispostula wow, thank you for this contribution! Good work, i will review it the next days :) Really appreciate your work!
Hi @PacoVK any chance to get a review soon?
@loispostula i am currently on it, but i am also a bit limited in time. So far looks good, to your question, there is not yet a migration mechanism in place. If you have suggestions, they are welcome. Most easy solution is to not migrate the keys, but set the scope per default not to namespace.
@loispostula could you also please add some documentation how eg. a namespace-scoped deploy key should look like?
@PacoVK Regarding the migration, I had a look at implementing a Migrator
service, that would work a bit like the bootstrap one, but then figured that I could not construct a scoped key from the existing one. You choose -
as as separator to bundle the scope information, but a module name or provider can have -
in it's name.
This means that a deploy key called terraform-my_module-tf
is easy to migrate but terraform-my-module-tf
is not.
Instead of going the migration route, I thus implemented retro-compatibility for existing keys.
Finally regarding documentation, happy to do it, but unsure the best place to do so
@loispostula thanks, yeah makes sense to support backwards-compatibility for the deploykeys. I took a look and really appreciate your work once again! Regarding docs you can put some guidance into the usage part. Maybe just about what is the purpose of having module/provider scoped vs. namespace scoped keys. If there are any advantages/disadantages and if you require to follow some naming-pattern (or you think there is a best practice) :)
@PacoVK thanks for the review, I've added the documentation, I think it's plenty sufficient to explain the behavior, but I'm happy to adapt
i think this looks complete! Thanks again, i will try to finish review, integrate and release that soon (hopefully this week already) Thanks again for the good work!
Description
implements #395
Type of change
Please delete options that are not relevant.
Improvements
@PacoVK I tested the PR and it works fairly well, the only remaining issues is the migration of existing keys. Is there already a migration mechanism in place? Migrating a key to the scopable one is easy, I just did not find where i could put the logic