feat(dev): observation print commands

[meganwolf0]

Description

Dev commands to print the associated resources and validation provided an Observation UUID

• Primary intent is to more easily identify associated resources/validation from observations when they don't pass - additional context is this was initially an effort for dash days to have automation surrounding previously passing, now failing observations/validations
• Limitation on the print-validation command is that the component definition must be composed, so the ID can be referenced from the back-matter. This is probably a larger can of worms on supporting the file path in that prop, but I feel like right now the cleanest case is to enforce that it must be composed

Related Issue

Fixes #621

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Schema Updates applied
• Contributor Guide Steps followed

[mildwonkey]

Seeing as we're re-using the print suffix, what do you think about lula dev print as a subcommand that takes either flags or arguments to identify what it's printing? Ie lula dev print --validation=<>, or lula dev print resource? (as a future feature we could then allow multiple print statements in one command)

[meganwolf0]

Seeing as we're re-using the print suffix, what do you think about lula dev print as a subcommand that takes either flags or arguments to identify what it's printing? Ie lula dev print --validation=<>, or lula dev print resource? (as a future feature we could then allow multiple print statements in one command)

Yeah looking back at the commands, there's a ton of logic overlap so that might be a fair way to refactor that. Let me poke at that a bit more and throw this back up

[meganwolf0]

@mildwonkey it's been thrown up 🤮 🤣

[mildwonkey]

I like it!! I think you still need to update the lula_dev docs but otherwise 👩🏻‍🍳 💋

[brandtkeller]

The logic itself I don't have much in the way of concerns. I'd like to document the constraints around composed component definitions as that looks like an obvious "gotcha" that will occur.

Otherwise my primary concern is command location - does a sub-command of dev feel appropriate here if the story we've been telling to-date is that dev is meant for validations and separate/distinct from OSCAL?

[meganwolf0]

The logic itself I don't have much in the way of concerns. I'd like to document the constraints around composed component definitions as that looks like an obvious "gotcha" that will occur.

Sounds good, I'll update the command help to try and highlight that constraint more. Might also add like a message to the user if a validation isn't found that the user should check they're using the composed component defn.

Actually, I just added the compose to that step - the wrinkle to that is that it doesn't currently support templating, but that might be something we can add via #771 ?

Otherwise my primary concern is command location - does a sub-command of dev feel appropriate here if the story we've been telling to-date is that dev is meant for validations and separate/distinct from OSCAL?

I guess I wasn't thinking dev was explicitly for validations, although I suppose that is all the functions at the moment, I think I was considering it more like as developer helper functions... but could do a different top level command for these? Or could just make the print it's own top level thing.

Our help text for dev is "Collection of dev commands to make dev life easier", our help text for tools is "Collection of additional commands to make OSCAL easier"... feels like this is a little of both haha, although print logic is more lula <> OSCAL specific rather than standalone OSCAL (since we're relaying on specific props/links) so maybe tools doesn't make sense either.

[brandtkeller]

Actually, I just added the compose to that step - the wrinkle to that is that it doesn't currently support templating, but that might be something we can add via #771 ?

That sounds good.

Our help text for dev is "Collection of dev commands to make dev life easier", our help text for tools is "Collection of additional commands to make OSCAL easier"... feels like this is a little of both haha, although print logic is more lula <> OSCAL specific rather than standalone OSCAL (since we're relaying on specific props/links) so maybe tools doesn't make sense either.

My wanting to think about command locality is still an open question that I've made for if lula dev could be used to support validation workflows without OSCAL - highlighting the value of the validations in isolation.

lula tools is typically where we have been dropping OSCAL helpers outside of the core functionality. That could be a contender? Optimally the Logic having a primary focus on OSCAL means that it would operate on OSCAL generically and lacking the required information would not outright error.

(maybe not in scope today) - This highlights another area of opportunity which is documenting the design - as this may be Lula opinionation today - but something we should look to have available for review and standardization from the OSCAL community provided there was interest - either in changing our logic or others following the pattern.

[meganwolf0]

@brandtkeller went ahead and moved the commands to tools, lmk if you think that fits better