-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prototype of template-based yamls as an alternative to basic example #3523
Conversation
…yaml Signed-off-by: 1000TurquoisePogs <[email protected]>
PAX build 3550 SUCCEEDED. |
Test workflow 3059 is started. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great ! I'm not that famliar with the imported keyring scenarios, but the pkcs12 and keyring generated and imported look really nice.
PAX build 3847 SUCCEEDED. |
Test workflow 3339 is started. |
PAX build 4537 SUCCEEDED. |
Test workflow 3967 is started. |
Closed for now due to defaults.yaml used elsewhere. Will revisit defaults.yaml enhancements over time. |
PR type
Relevant issues
Resolves zowe/community#1884
Evolution of #3356
Changes proposed in this PR
This PR introduces a new way to setup zowe.
Instead of just getting example-zowe.yaml and editing it, there are 2 files:
The defaults.yaml, though more work due to needing to use the advanced
CONFIG=FILE(/path/to/my-config.yaml):FILE(/path/to/default.yaml)
syntax, gives advantage of users not needing to take action upon upgrades to zowe: default.yaml will change at our discretion to give the user a smooth upgrade experience.The idea is, the user finds whichever template yaml that best suits their keystore need, and then edits that, which should require less edits overall due to templates.
These yamls now also have new comments which are hopefully more helpful than before.
Does this PR introduce a breaking change?