-
Notifications
You must be signed in to change notification settings - Fork 28
Onboard Intake (1/3): introduce intake runner command #952
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
Conversation
|
Sample CLI usage: |
732eff1 to
669dbb9
Compare
|
PS: notice that I messed up the branch by mistake, I had to cherry-pick until 7868e56 (last commit reviewed) and force push. |
|
Rest looks good to me. :) |
|
This PR was marked as stale after 7 days of inactivity and will be closed after another 7 days of further inactivity. If this PR should be kept open, just add a comment, remove the stale label or push new commits to it. |
|
keep PR open |
rubenhoenle
left a comment
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.
Please check the failing CI pipeline
# Conflicts: # go.mod # go.sum
rubenhoenle
left a comment
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.
see above
rubenhoenle
left a comment
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.
see above
Description
This PR onboards the new STACKIT Intake (ticket) service into the CLI.
Intake is composed of three components:
This PR contains the Intake Runners part only to make a quicker and less overwhelming review. The remaining code (2/3) can be submitted as part of this PR once the first batch has been reviewed/approved or we can open a different PR for it (as the maintainer please).
The commands are designed to work as follows:
Most customers will use
intakeshence why we decided to go with this command structure. The folder structure will look like the following due to the hierachy desired:Checklist
make fmtmake generate-docs(will be checked by CI)make test(will be checked by CI)make lint(will be checked by CI)