Nice work on the token use and robot generation! I mostly have some nitpicks and formatting critiques but overall it feels like you're headed in the right direction!
I know it's a POC so not necessary right now but overtime I’d like to see some more typehints in function signatures, eg: def flatten(l: list):
https://github.com/Peikae3IWaeG/robotgen/blob/main/helpers.py#LL159C1-L159C16
Static analysis falls apart for python in larger frameworks but for custom functions, utils, data structures, it’s handy to have them 😄
When I was at this stage:
I was a bit confused how the regex capture group field relates back to the raise issue (I know internally because I wrote the parsers :P but in terms of new user UX) - I know it’s a placeholder UI but I’d recommend moving the regex group name, and assertion on the same line as Raise Issue If, that way it reads like: Raise issue if _line Contains Crashloop
Just so it flows a bit better for when the rest of the team tries it out.
WRT the binary option, not all cmds are guaranteed to start with the binary name explicitly, and it’s used as a way to effectively sed one binary name for another across a whole string. That way if people have kubectl commands (which could contain forloops, pipes, other binaries, etc) they like, but need to swap it out for oc instead, they just swap the enum and it gets replaced. In this case:
I submitted: kubectl get pods -o=name | grep mypod | xargs oc get -oyaml
I got: kubectl kubectl get pods -o=name | grep mypod | xargs oc get -oyaml
For the prototype I’d recommend giving back something like:
${KUBERNETES_DISTRIBUTION_BINARY} get pods -o=name | grep mypod | xargs ${KUBERNETES_DISTRIBUTION_BINARY} get -oyaml
The example does nothing useful and is just to show some variance.
jon-funk
commented
1 year ago
Nice work on the token use and robot generation! I mostly have some nitpicks and formatting critiques but overall it feels like you're headed in the right direction!
I know it's a POC so not necessary right now but overtime I’d like to see some more typehints in function signatures, eg: def flatten(l: list): https://github.com/Peikae3IWaeG/robotgen/blob/main/helpers.py#LL159C1-L159C16 Static analysis falls apart for python in larger frameworks but for custom functions, utils, data structures, it’s handy to have them 😄
When I was at this stage:
I was a bit confused how the regex capture group field relates back to the raise issue (I know internally because I wrote the parsers :P but in terms of new user UX) - I know it’s a placeholder UI but I’d recommend moving the regex group name, and assertion on the same line as Raise Issue If, that way it reads like: Raise issue if _line Contains Crashloop
Just so it flows a bit better for when the rest of the team tries it out.
WRT the binary option, not all cmds are guaranteed to start with the binary name explicitly, and it’s used as a way to effectively sed one binary name for another across a whole string. That way if people have kubectl commands (which could contain forloops, pipes, other binaries, etc) they like, but need to swap it out for oc instead, they just swap the enum and it gets replaced. In this case:
I submitted: kubectl get pods -o=name | grep mypod | xargs oc get -oyaml I got: kubectl kubectl get pods -o=name | grep mypod | xargs oc get -oyaml
For the prototype I’d recommend giving back something like: ${KUBERNETES_DISTRIBUTION_BINARY} get pods -o=name | grep mypod | xargs ${KUBERNETES_DISTRIBUTION_BINARY} get -oyaml The example does nothing useful and is just to show some variance.