datasize, blueprint: add new datasizes.Size type and use in blueprints #1057
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
achilleas-k
changed the title
This commit adds a new `datasizes.Size` type that is an alias
for uint64 but has supports direct json/toml decoding. So sizes
can be specified as 123, "123" or "123 GiB" and this is transparently
handled.
datasizes: tweak error return to avoid "stuttering"
The `datasizes.Size.UnmarshalJSON()` returns a `JSON unmarshal`
prefix. However this is a bit too generic as other (nested)
unmarshalers may also use the prefix. So instead just indicate
the type in the error string itself:
```
error decoding {TOML,JSON} size: ...
```
achilleas-k
previously approved these changes
Nov 22, 2024
achilleas-k
reviewed
Nov 22, 2024
This commit decouples the marshaling representation of the `FilesystemCustomization` from the actual struct. This means that we can reuse custom unmarshaling via datasizes.Size and also have our external represenation "pure". If we continue using this pattern is also means that we can rename fields in the marshaling and provide compatbility easily. Thanks to Thozza, c.f. osbuild#1049 (comment) and osbuild#983
This commit fixes the issue that minsize cannot be a string by using the existing pattern. See osbuild#1055 for the alternative approach.
mvo5
force-pushed
the
datasizes-2-return-of-the-decoupler
branch
from
87664dd to
bf18923
Compare
mvo5
commented
Nov 22, 2024
| ) | ||
|
|
||
| // XXX: move to interal/common ? | ||
| func unmarshalTOMLviaJSON(u json.Unmarshaler, data any) error { |
There was a problem hiding this comment.
This should probably grow it's own test.
achilleas-k
approved these changes
Nov 22, 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.
This is an alternative implementation of the idea in #1049 based on feedback from @thozza (thanks!).
blueprint: decouple FilesystemCustomization from marshaling
This commit decouples the marshaling representation of the
FilesystemCustomizationfrom the actual struct. This means thatwe can reuse custom unmarshaling via datasizes.Size and also
have our external represenation "pure".
If we continue using this pattern is also means that we can rename
fields in the marshaling and provide compatbility easily.
Thanks to Thozza, c.f.
#1049 (comment)
and
#983
datasizes: add new
Sizetype with json/toml decodingsupport
This commit adds a new
datasizes.Sizetype that is an aliasfor uint64 but has supports direct json/toml decoding. So sizes
can be specified as 123, "123" or "123 GiB" and this is transparently
handled.