Update service level readme #3267
Conversation
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
sima-zhu
added
the
Central-EngSys
|
@sima-zhu is there an associated issue that this PR should be linked to? Also what is the overall plan here? Do we want to only generate it but manually use it if teams want to? |
|
@weshaggard I just created an issue with the proposal inside. It is linked through the connect issue. |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
| $servicePackages = $packagesForService.Values.Where({ $_.ServiceName -eq $service }) | ||
|
|
||
|
|
||
| $serviceReadmeBaseName = $service.ToLower().Replace(' ', '-').Replace('/', '-') |
There was a problem hiding this comment.
In this case we replace space with - but in other metadata-helpers we replace space with empty. Should those be consistent? If so this transform seems like a good helper function to share the implementation.
There was a problem hiding this comment.
We should align this with toc.
Totally agree to have helper function.
Will have helper function and align with toc for now.
Will sync with @danieljurek for the most accurate fix.
There was a problem hiding this comment.
The place in metadata is to read the service from github codeowner files. The naming strategy are not the same.
| @@ -0,0 +1,37 @@ | |||
| function GetPackageKey($pkg) { | |||
There was a problem hiding this comment.
Do you expect to consume these helpers in the other script at a later point?
There was a problem hiding this comment.
Yes, minimize the scope of the script for now.
| $packageLevelReadme = "" | ||
| if (Test-Path "Function:$GetPackageLevelReadmeFn") { | ||
| $packageLevelReadme = &$GetPackageLevelReadmeFn -packageMetadata $pkg | ||
| } |
There was a problem hiding this comment.
If this function doesn't exist in a language will this produce an invalid result?
There was a problem hiding this comment.
We used the function to find the package level readme.
If not exist, then the return is invalid package level readme, then we do not add the link under reference table
There was a problem hiding this comment.
This is the path check:
(Test-Path (Join-Path $readmeFolder -ChildPath "$packageLevelReadme-readme.md"))
There was a problem hiding this comment.
A couple comments but otherwise looks good. Please finish your testing and reach out to @scbedd for one more pass.
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
|
||
| Set-StrictMode -Version 3 | ||
|
|
||
| function create-metadata-table($readmeFolder, $readmeName, $moniker, $msService, $clientTableLink, $mgmtTableLink, $serviceName) |
There was a problem hiding this comment.
Is there a guiding principle in the naming convention? snake-like-case vs PascalCase like the next function below?
| $null = New-Item -Path $readmePath -Force | ||
| $lang = $LanguageDisplayName | ||
| $langTitle = "Azure $serviceName SDK for $lang" | ||
| $header = GenerateDocsMsMetadata -language $lang -langTitle $langTitle -serviceName $serviceName ` |
There was a problem hiding this comment.
Just FYI. this "header" thing is called the yml front-matter by the docs team. No reason to rename at this point, but I'll remind on your next pass over this code.
There was a problem hiding this comment.
Rename is not a big deal. Will align with the docs and add comments for reference.
| Add-Content -Path $readmePath -Value $content | ||
| } | ||
|
|
||
| function CompareAndMergeMetadata ($original, $updated) { |
There was a problem hiding this comment.
Intentional to only handle adds right? Removes will be rare enough that we will handle them manually?
There was a problem hiding this comment.
Exactly. So people is able to add specific metadata for their service needs without override
There was a problem hiding this comment.
Have some clarifying questions, but nothing jumps out at me anymore!
Integration PR will be per language correct?
Adding the call to Service-Level-Readme-Automation.ps1 as well as populating LanguageSettings:
- Get-${Language}-OnboardedDocsMsPackagesForMoniker
- Get-${Language}-PackageLevelReadme
You are exactly right for the step moving forward. This is very initial implementation. Will have several followups to launch this. |
|
The following pipelines have been queued for testing: |
|
Hello @azure-sdk! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
ghost
merged commit 
Docs.Ms does not have service level readme automation.
This is a miss on the docs automation.
Have the daily docindex to generate the service level readme.
Generate the {*-index.d} for client packages and mgmt packages table.
Testing in JS: https://github.com/Azure/azure-sdk-for-js/pull/21707/files
https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1605400&view=results
Service level Readmes:
https://github.com/MicrosoftDocs/azure-docs-sdk-node/blob/daily/2022-05-02-ci-succeeded/docs-ref-services/latest/storage.md
Docs.Ms:
https://review.docs.microsoft.com/en-us/javascript/api/overview/azure/key-vault?view=azure-node-latest&branch=daily%2F2022-05-02-ci-succeeded
In docs.ms:
In service level readme:
Resolve #3278