-
Notifications
You must be signed in to change notification settings - Fork 21
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
Adds a workflow to create an AIO #1150
base: stackhpc/2023.1
Are you sure you want to change the base?
Conversation
This is useful for debugging.
Remove file as I'm testing in the other one
@@ -1,328 +1,36 @@ | |||
--- |
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.
What's going on here?
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.
Oh, it so I could test it before merging. I needed the action to already exist in https://github.com/stackhpc/stackhpc-kayobe-config/actions
to be able to trigger it before merging . The idea was to move to a new file once it worked. Not sure if there is an easier way?
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.
perhaps add a workflow_dispatch trigger to the PR workflow?
%{ if debug_ssh_key != "" } | ||
- ${debug_ssh_key} | ||
%{ endif } |
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.
I like this approach. We should do something similar for multinodes.
This creates an AIO with the usual workflow but doesn't delete it. The idea is you can login with a secondary key and debug why the failure is occurring. Just remember to manually delete the VM afterwards.