[keyvault] samples updates for doc publishing#6626
[keyvault] samples updates for doc publishing#6626willmtemple merged 15 commits intoAzure:masterfrom
Conversation
…fault. - Sample build is potentially destructive, so disabling sample build until it can be made non-destructive.
… making destructive changes
| await client.mergeCertificate("MyCertificate", [Buffer.from(base64Crt)]); | ||
| } | ||
|
|
||
| module.exports = { main }; |
There was a problem hiding this comment.
This was mentioned in the TypeScript meeting. Just wanted to throw my vote in for autogenerating this so it's easier for people to take examples straight from the repo.
There was a problem hiding this comment.
Yes, I'd like to get rid of this and modify the prep-samples script to insert it, but I will have to do it for every sample at the same time in another PR. I could make changes to the storage ones in this PR, but I have another PR for some fixes to storage samples open right now so I think it would be best to do them all mechanically in a third PR.
There was a problem hiding this comment.
Let's use a separate PR to make that change in both keyvaults and storage at the same time and use this PR to get keyvault samples to be in a runnable state by scripts
| const { DefaultAzureCredential } = require("@azure/identity"); | ||
|
|
||
| // Load the .env file if it exists | ||
| require("dotenv").config(); |
There was a problem hiding this comment.
Would it be possible to auto-generate this?
There was a problem hiding this comment.
The dotenv bits are for end-users of the samples. CI won't need them. The sample readme presents use of dotenv as an option, so this part has to be checked in for that to work when a customer downloads the sample zip file.
There was a problem hiding this comment.
Thinking through the concepts we're asking the user to understand to use the samples, I wonder if we should just mention this in the docs but not in the samples to keep the samples "as simple as possible".
It's nice to have the option to use .env if that's what the user wants to do, but if they'd rather just update the environment where their app lives, they don't actually need the .env part for the sample to work.
|
/azp run js - keyvault - ci |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run js - keyvault-keys - tests |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I added |
|
Storage packages have an environment for executing the samples in Linux that's configured as part of the tests pipeline. As far as I know, they're the only ones. However, in storage, those pipelines don't have the environment variables for AAD rbac, so the AAD tests are skipped there. Here in keyvault, we'll need to make sure that they are available since all the samples use them. |
|
I'm going to rewrite history here so that we can merge the samples and get them live, then we can worry about the CI part of it later once that infrastructure is in place. CC @sadasant |
97b9031 to
21baee6
Compare
|
/azp run js - keyvault-keys - tests |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| "build:nodebrowser": "rollup -c 2>&1", | ||
| "build:test": "npm run build:es6 && rollup -c rollup.test.config.js 2>&1", | ||
| "build": "npm run extract-api && npm run build:samples && npm run build:es6 && npm run build:nodebrowser", | ||
| "build": "npm run extract-api && npm run build:es6 && npm run build:nodebrowser", |
There was a problem hiding this comment.
I'd like to keep building the samples in here in some capacity so that if we break the samples the CI will warn us.
| const { DefaultAzureCredential } = require("@azure/identity"); | ||
|
|
||
| // Load the .env file if it exists | ||
| require("dotenv").config(); |
There was a problem hiding this comment.
Going forward, are we recommending users put this in their projects?
| const { DefaultAzureCredential } = require("@azure/identity"); | ||
|
|
||
| // Load the .env file if it exists | ||
| require("dotenv").config(); |
There was a problem hiding this comment.
Thinking through the concepts we're asking the user to understand to use the samples, I wonder if we should just mention this in the docs but not in the samples to keep the samples "as simple as possible".
It's nice to have the option to use .env if that's what the user wants to do, but if they'd rather just update the environment where their app lives, they don't actually need the .env part for the sample to work.
Similar to #6496 but for keyvault. Addresses #5679 CC @sadasant
Fixes #6625
Changes:
NOTES by @sadasant: