Separate weekly openApi-doc refresh and command-metadata refresh#3467
Separate weekly openApi-doc refresh and command-metadata refresh#3467ramsessanchez wants to merge 15 commits intomainfrom
Conversation
MIchaelMainer
left a comment
MIchaelMainer
left a comment
There was a problem hiding this comment.
I'm curious how much this reduces the average generation run.
| type: string | ||
| - name: BuildAgent | ||
| displayName: Build Agent | ||
| - name: SkipForceRefresh |
There was a problem hiding this comment.
Why are these removed?
There was a problem hiding this comment.
SkipForceRefresh is unnecessary, the skipDownload parameter covers this. After reviewing the pipeline logic, I noticed that there is no scenario where one is true and the other is false. In the use cases for this workflow, they are both either false or both true, so it makes sense that these parameters are consolidated into one.
There was a problem hiding this comment.
Further, this pipeline is called by the weeklyGeneration pipeline. That pipeline contains the skipDownload parameter, which will skip this workflow altogether if set to True. Therefore, these parameters are unnecessary here and consolidated in the weeklyGeneration pipeline.
| targetType: inline | ||
| script: | | ||
| git status | ||
| git branch $(ComputeBranch.WeeklyBranch) |
There was a problem hiding this comment.
Is the task variable name optional for specifying an environment variable set from an ADO task? I haven't seen this before
There was a problem hiding this comment.
The task variable name should be optional; it is helpful for scope though. That being said, I noticed that the scope here was incorrect for this variable, adding a fix.
| sdl: | ||
| binskim: | ||
| enabled: false | ||
| justificationForDisabling: "Binskim keeps on crashing and failing the weekly build pipeline. Disabling it for now because we are unable to publish the artifacts to internal feeds." |
There was a problem hiding this comment.
Do we understand why it is failing?
There was a problem hiding this comment.
Not aware of why or where this fails. This portion of the pipeline is actually just directly pulled from out current weekly-generation and ci-build pipelines. This seems to have been present for a long time now and I made the choice to keep this configuration to prevent possible failures.
2 participants
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.yml
Individual-Workload-Module.yml
The 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.
command-metadata-refresh.yml
Note: 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.