-
Notifications
You must be signed in to change notification settings - Fork 28
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
Add tags to identify read-only resources #805
Conversation
Codecov Report
@@ Coverage Diff @@
## main #805 +/- ##
==========================================
+ Coverage 95.57% 95.89% +0.32%
==========================================
Files 18 18
Lines 294 317 +23
==========================================
+ Hits 281 304 +23
Misses 13 13
Flags with carried forward coverage won't be shown. Click here to find out more.
|
I've scoped this PR down to just include ReadOnly and WriteOnly flags on resources. There are a few related concerns that have been spun off into separate issues that warrant some more discussion. #838 shows the type generation updates that will follow from this PR. |
The changes look sensible - just working through the type generation PR. I thought it would be easiest if I add my comments directly there. Do you have any ideas on improving the review process for this monstrous set of changes, or suggestions for things to focus on? |
By the way, I would recommend giving the following users/teams a heads-up on these changes:
@alex-frankel are you aware of any other non-obvious dependencies on this repo? |
Unfortunately, no. The .md files are more compact than the logs, but there are apparently a ton of read-only resources. |
Thanks for letting me know about this change. Just to make sure I understand it - it looks like many resource types were added that are marked as "(ReadOnly)" at the end of the first line of the resource definition. These seem to all be types that were not appearing before in the generated types. My process will block those types for published docs. Let me know if any of my assumptions are wrong or if there are other changes I need to be aware of. |
@anthony-c-martin Would it make sense to release new types resulting from this change as version 0.2.0? Azure.Bicep.Types is currently on 0.1.486, and a transition from 0.1.x -> 0.2.x would allow for breaking changes. |
9c7bff1
to
0e3d296
Compare
0e3d296
to
c74a5d5
Compare
…g rebase was too difficult)
c74a5d5
to
ace36df
Compare
…nd a parameterized-name GET (or vice versa)
…to the integration test
…pecific readonly flags
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.
… the same definition
Doesn't hurt! |
if (ns.type === 'parameterized') { | ||
const {schema} = ns; | ||
if (schema instanceof ConstantSchema && toBuiltInTypeKind(schema.valueType) === BuiltInTypeKind.String) { | ||
nameLiterals.add(schema.value.value); | ||
} else if (schema instanceof ChoiceSchema || schema instanceof SealedChoiceSchema) { | ||
const enumValues = getValuesForEnum(schema); | ||
if (enumValues.success) { | ||
const {values, closed} = enumValues.value; | ||
values.forEach(v => nameLiterals.add(v)); | ||
if (!closed) { | ||
nameTypes.add(BuiltInTypeKind.String); | ||
} | ||
} | ||
} else { | ||
nameTypes.add(toBuiltInTypeKind(schema)); | ||
} | ||
} else { | ||
nameLiterals.add(ns.value); | ||
} | ||
} | ||
|
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.
First off, I apologize for the general lack of comments in this repo. The code is already difficult to follow, and with the handling of more corner cases, it's becoming more complex. No need to address in this PR, but going forwards I think it might be worth thinking about starting to add some comments to explain some of the more complex logic.
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.
I did add one comment for this section, but I agree that it would be a good idea to put more in going forward.
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.
Looks good!
With #874, #884, and #921 in master, the typegen diff (viewable as #838) ended up being a lot more manageable (at least wrt the markdown and log files). I was able to verify that the effect of this PR was almost entirely additive (with 8 existing resources gaining a new |
Resolves #411.
This PR adds a
Flags
property to the serialized bicep resource type to inform the compiler whether resources are read-only, write-only, or support both reading and writing. This will allow the compiler to handleexisting
resources for read-only types while disallowing their use as regular resource types.For backwards compatibility, flags only indicate deviations from the norm, so
ResourceFlags.None
represents a resource that is both readable and writable. TheBicep.Types
library, even with this change, will treat existing serialized resources as having a flag ofResourceFlags.None
, so there's no need to coordinate a release of that library with one of the k8s types.