add activation keys docs #187
Conversation
|
🚀 Preview is available at https://pr-187--konflux-docs.netlify.app |
|
🚀 Preview is available at https://pr-187--konflux-docs.netlify.app |
| Alternatively, you can create the secret through the CLI. After logging into your cluster and navigating to your namespace, run the following command: | ||
|
|
||
| ---- | ||
| kubectl create secret generic activation-key -n <your-tenant> --from-literal=org=<your org id> --from-literal=activationkey=<your activation key name> |
There was a problem hiding this comment.
This will make activation keys "just work" because of the default value of the parameter, correct? Would it be better if we suggested that an activation key is created with a unique name and require users to explicitly set the parameter (I guess they would need to set it on the pipelinerun, pipeline, and the task so that it is properly passed)?
There was a problem hiding this comment.
I added a new section to explain how naming impacts the scope of the key
|
|
||
| === Automatic registration | ||
|
|
||
| The buildah task will use a provided activation key to register itself with Red Hat subscription manager and moount the necessary credentials so that can be used by the builds. |
There was a problem hiding this comment.
If we use suggest the default activation key, can we inform users how to override the parameter so that a configured activation key isn't used everywhere?
There was a problem hiding this comment.
instead, I added a section advising the user to not use the default name unless they want the key to be used for all builds in the workspace. The pattern of adding a "dummy name" pointing to a non-existent key does work, but I think it seems like a weird thing to instruct people to do
…r not (scope impact of the added key)
|
🚀 Preview is available at https://pr-187--konflux-docs.netlify.app |
No description provided.