refactor!: #388 update types to use pointers #410
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3 tasks
✅ Deploy Preview for lula-docs canceled.
|
…ointers-similar-to-go-oscal
refactor!(component): change NewOscalComponentDefinitionFromBytes to return a pointer
…ointers-similar-to-go-oscal
…nters, updated references
…ointers-similar-to-go-oscal
…rce for the extension refactor!(catalog): now uses pointers
… source in favor of oscal validation refactor!(component): delete the NewOscalComponentDefinitionFromBytes method in favor of NewOscalComponentDefinition refactor!(common): rename WriteFile -> WriteOscalModel refactor(generate): WriteFile -> WriteOscalModel refactor(composition): removed validation logic in favor of NewOscalCOmponentDefinition handling it feat(common): WriteOscalModel now handles json file extensions feat(evaluate): now runs file extension validation for json/yaml feat(validate): now checks input file for extension tests: update tests, update test data to pass oscal validation
…omplete-schema)
…nstructors and updated all relavant constructors
…talog to use pointers refactor(generate): update all refs to ComponentFromCatalog
…ointers-similar-to-go-oscal
mike-winberry
requested review from
brandtkeller,
CloudBeard and
meganwolf0
as code owners
meganwolf0
reviewed
May 15, 2024
There was a problem hiding this comment.
A couple things I noticed:
- When I tried composing some local files I have, I noticed sometimes the rego would be just a giant string (which is real hard to read/edit) and other times it was actually formatted properly. I had both seemingly structured the same by the look of things in the editor, but I assume there's some hidden characters there that's messing with the input/output. Wondering if that's something we could fix? (see
pepr_validationsbranch in compliance-artifacts for the pepr.yaml I composed.) I suppose it's down to if we intend people to edit these after they've been composed - During this exercise I also noticed that some empty fields in the validation.yaml were being rendered as well (for the respective 'spec' chosen, e.g., Kubernetes-spec shows empty
fieldandwaitfields). Wondering if we should pointer-ize those too? (also possibly add some omitempty's)
|
meganwolf0
previously approved these changes
May 22, 2024
…ointers-similar-to-go-oscal
…ointers-similar-to-go-oscal
…ointers-similar-to-go-oscal
meganwolf0
approved these changes
May 23, 2024
brandtkeller
approved these changes
May 23, 2024
…ointers-similar-to-go-oscal
mike-winberry
deleted the
388-discussion-should-we-move-our-types-to-pointers-similar-to-go-oscal
branch
This was referenced May 23, 2024
This was referenced Jun 29, 2024
This was referenced Jul 12, 2024
This was referenced Aug 5, 2024
This was referenced Oct 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
...
Related Issue
#388
#403
Type of change
Checklist before merging