-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[keyvault] samples updates for doc publishing #6626
[keyvault] samples updates for doc publishing #6626
Conversation
…fault. - Sample build is potentially destructive, so disabling sample build until it can be made non-destructive.
… making destructive changes
@@ -58,6 +65,8 @@ ${base64Csr} | |||
await client.mergeCertificate("MyCertificate", [Buffer.from(base64Crt)]); | |||
} | |||
|
|||
module.exports = { main }; |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to auto-generate this?
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 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:es6": "tsc -p tsconfig.json", | ||
"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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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: