-
Notifications
You must be signed in to change notification settings - Fork 212
Split Weekly Generation Pipeline #3430
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
base: dev
Are you sure you want to change the base?
Conversation
Split Weekly generation pipeline into two separate pipelines, one to retrieve openApi updates and individually build the modules. A second pipeline to take the current api docs and generate the commandMetadata when we approach a release date.
|
The following demonstrates ability to build modules individually: |
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.
Pull Request Overview
This PR splits the weekly generation pipeline into two separate pipelines: one for OpenAPI document validation (weekly-generation.yml) and another for command metadata generation (module-metadata-generation.yml). The first pipeline downloads OpenAPI docs, identifies changed modules, builds them independently in parallel for validation, and creates a PR with updated OpenAPI documents. The second pipeline (triggered on merges to dev) builds all modules together and generates command metadata.
Key changes:
- Introduced a matrix strategy to build modules independently in parallel based on detected OpenAPI changes
- Created a new standalone pipeline for metadata generation that builds all modules on a single image
- Added parameters to optionally specify which modules to generate for testing purposes
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
.azure-pipelines/weekly-generation.yml |
Restructured to use matrix strategy for parallel module builds, removed metadata generation steps, added module specification parameters |
.azure-pipelines/module-metadata-generation.yml |
New pipeline for building all modules together and generating command metadata, triggered on dev branch merges |
.azure-pipelines/generation-templates/individualized-workload-modules.yml |
New template for building individual modules with module name and version parameters |
.azure-pipelines/common-templates/download-openapi-docs.yml |
Updated module change detection to include version suffix in module names |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
.azure-pipelines/generation-templates/individualized-workload-modules.yml
Outdated
Show resolved
Hide resolved
|
@ramsessanchez do we have any preliminary pipeline runs that use these updated scripts? |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Assuming you're talking about the script in download-openApi .yml? No other pipelines use this outside of the weekly generation pipeline. The update focuses on making sure that the list of modules in the diff are listed with v1.0 or beta label, for the purpose of the module build matrix. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
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.
Pull Request Overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| targetType: inline | ||
| pwsh: true | ||
| script: | | ||
| . $(System.DefaultWorkingDirectory)/tools/GenerateModules.ps1 -SkipGeneration -Pack -ArtifactsLocation $(Build.ArtifactStagingDirectory) No newline at end of file |
Copilot
AI
Oct 28, 2025
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 Pack step does not pass the -ModuleToGenerate and -ApiVersion parameters that were used in the Generate step (line 29). This will cause the Pack command to attempt packing all modules instead of just the specific module that was generated, which is inconsistent with the individualized approach.
| . $(System.DefaultWorkingDirectory)/tools/GenerateModules.ps1 -SkipGeneration -Pack -ArtifactsLocation $(Build.ArtifactStagingDirectory) | |
| . $(System.DefaultWorkingDirectory)/tools/GenerateModules.ps1 -SkipGeneration -Pack -ArtifactsLocation $(Build.ArtifactStagingDirectory) -ModuleToGenerate ${{ parameters.ModuleName }} -ApiVersion ${{ parameters.ModuleVersion }} |
| moduleName = $item | ||
| } | ||
| } else { | ||
| $name, $version = $item -split '_' |
Copilot
AI
Oct 28, 2025
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 script splits on underscore to extract name and version, but module names may contain underscores (e.g., 'Identity_SignIns'). This will incorrectly split such module names. Consider using -split '_', 2 to limit the split to a maximum of 2 parts, or use a different approach to extract the last segment as the version.
| $name, $version = $item -split '_' | |
| $segments = $item -split '_' | |
| $version = $segments[-1] | |
| $name = ($segments[0..($segments.Length - 2)] -join '_') |
| if ($item -notmatch '_') { | ||
| # If '_' is not present, create two versions: v1.0 and beta | ||
| $jsonOutput["${item}_v1.0"] = @{ | ||
| moduleVersion = 'v1.0' | ||
| moduleName = $item | ||
| } | ||
| $jsonOutput["${item}_beta"] = @{ | ||
| moduleVersion = 'beta' | ||
| moduleName = $item | ||
| } | ||
| } else { | ||
| $name, $version = $item -split '_' | ||
| $jsonOutput[$item] = @{ | ||
| moduleVersion = $version | ||
| moduleName = $name | ||
| } |
Copilot
AI
Oct 28, 2025
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 logic assumes that items without underscores should generate both v1.0 and beta versions. However, this conflicts with the updated download-openapi-docs.yml (line 78) which now always includes the version suffix. This means items will always contain '_', making this branch unreachable. Either remove this dead code or update the logic to handle the new format.
| if ($item -notmatch '_') { | |
| # If '_' is not present, create two versions: v1.0 and beta | |
| $jsonOutput["${item}_v1.0"] = @{ | |
| moduleVersion = 'v1.0' | |
| moduleName = $item | |
| } | |
| $jsonOutput["${item}_beta"] = @{ | |
| moduleVersion = 'beta' | |
| moduleName = $item | |
| } | |
| } else { | |
| $name, $version = $item -split '_' | |
| $jsonOutput[$item] = @{ | |
| moduleVersion = $version | |
| moduleName = $name | |
| } | |
| $name, $version = $item -split '_' | |
| $jsonOutput[$item] = @{ | |
| moduleVersion = $version | |
| moduleName = $name |
| if ($_ -match 'openApiDocs\/(v1.0|beta)\/(.*)\.yml') { | ||
| $version = if ($matches[1] -eq 'v1.0') { 'v1.0' } else { 'beta' } | ||
| $moduleName = "$($matches[2])_$version" | ||
| if (!$ModulesWithChanges.ContainsKey($moduleName)) { | ||
| $ModulesWithChanges.Add($moduleName, $matches[1]) | ||
| } |
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.
Seeing a script this complex inline in a pipeline makes me a bit nervous.
yaml is not a great authoring tool for multiline scripts.
If this were refactored into a stand-alone script that you could call then your can test it independent of a pipeline run.
Plus you could eliminate the if statment in here an use a condition on the step combined with setting the ModulesWithChanges variable to 'Skipped' by default.
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.
Gotcha. Included the above runs as references showing that the scripts did work. Initially I was just editing the inline scripts that were already there, however as the complexity grew they definitely should have been moved to their own file. Will update with the changes.
| targetType: inline | ||
| pwsh: true | ||
| script: | | ||
| if ($${{ parameters.SpecifyModules }}) { |
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.
Again, I'd refactor this to a script so that you can test it on your own without having to run a pipeline
Split Weekly generation pipeline into two separate pipelines, one to retrieve openApi updates and individually build the modules, and a second pipeline to generate the comandMetadata which requires all modules build on a single image.
The following yml files handle the following:
1.) downloading the most recent openApi docs
2.) determine which modules have been updated
3.) build the updated modules independently to validate openApi document correctness
4.) if all updated modules build successfully then a PR is created with the updated openApi documents.
Weekly-Generation.ymlIndividualized-Workload-Modules.ymlThe second will be triggered on merges to Dev and can also be triggered manually.
1.) All modules are built on a single image
2.) the commandMetadata is generated after all modules are built.
3.) successful completion of both results in a pull request into the Dev branch with an updated commandMetadata file.
Module-Metadata-generation.ymlNote: The second pipeline is still in testing as we can't test the pipeline fully until we have it registered as one of our pipelines in devops and add the appropriate token.