[KeyVault] - Added immutable flag to key release policy#20090
[KeyVault] - Added immutable flag to key release policy#20090maorleger merged 5 commits intoAzure:mainfrom
Conversation
| }; | ||
|
|
||
| /** Known values of {@link EncryptionAlgorithm} that the service accepts. */ | ||
| export enum KnownEncryptionAlgorithms { |
There was a problem hiding this comment.
Oh yeah, I forgot I did this. At some point the swagger removed all these comments and I got tired of adding them back in every time I regenerate!
There was a problem hiding this comment.
Can you prevent the generated enum from ending up in source then? Or is the idea with minimization is that apps should use webpack or something to remove unused code?
There was a problem hiding this comment.
We already GA'd with this enum in-place, it was just re-exported directly from generated code
| DeletionRecoveryLevel, | ||
| KnownDeletionRecoveryLevel, | ||
| KeyVaultClientGetKeysOptionalParams, | ||
| GetKeysOptionalParams, |
There was a problem hiding this comment.
These changes just absorb the corresponding name changes in the TS codegen so we can use the latest and greatest
|
API changes have been detected in API changes + immutable?: boolean;
- export declare enum KnownJsonWebKeyEncryptionAlgorithm
+ export declare enum KnownEncryptionAlgorithms |
This is a bug in APIView / api-extractor and not a real change. The problem is that it misrepresents something that is either imported with a rename (import {x as y}) or exported under a different name (export { x as y }) - I forget if it's just the former or both cases 😄 If you look at our published docs or pull the last beta / GA you can see that it is clearly named |
| }; | ||
|
|
||
| /** Known values of {@link EncryptionAlgorithm} that the service accepts. */ | ||
| export enum KnownEncryptionAlgorithms { |
There was a problem hiding this comment.
Can you prevent the generated enum from ending up in source then? Or is the idea with minimization is that apps should use webpack or something to remove unused code?
### Packages impacted by this PR @azure/keyvault-keys ### Issues associated with this PR Resolves Azure#19857 ### Describe the problem that is addressed by this PR Now that this flag has been added we can regenerate code and add support for immutable key release policies. Once a policy is marked immutable it can no longer be modified. ### Are there test cases added in this PR? _(If not, why?)_ Yes, I debated whether I should also add a test case for "create a key, then update the release policy to be immutable, then try to change it" but it wouldn't drive any code so I skipped it. Do note that since MHSM does not currently support this flag I was unable to add a test for it for MHSM, but I will create an issue to add that in later.
Packages impacted by this PR
@azure/keyvault-keys
Issues associated with this PR
Resolves #19857
Describe the problem that is addressed by this PR
Now that this flag has been added we can regenerate code and add support for
immutable key release policies. Once a policy is marked immutable it can no
longer be modified.
Are there test cases added in this PR? (If not, why?)
Yes, I debated whether I should also add a test case for "create a key, then
update the release policy to be immutable, then try to change it" but it
wouldn't drive any code so I skipped it.
Do note that since MHSM does not currently support this flag I was unable to add
a test for it for MHSM, but I will create an issue to add that in later.
Checklists