-
Notifications
You must be signed in to change notification settings - Fork 70
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
Added release logic to Optimization Engine #703
base: features/aoe
Are you sure you want to change the base?
Conversation
Co-authored-by: Michael Flanakin <[email protected]>
Co-authored-by: Michael Flanakin <[email protected]>
Co-authored-by: Michael Flanakin <[email protected]>
Co-authored-by: Michael Flanakin <[email protected]>
@@ -118,3 +118,28 @@ Get-ChildItem "$PSScriptRoot/../templates/$Template*" -Directory -ErrorAction Si | |||
|
|||
Write-Host '' | |||
} | |||
|
|||
# Package optimization engine |
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.
nit: Should we move this into a separate Build-OptimizationEngine script? π€ I'm fine keeping it here. Just thinking out loud. Fwiw, the templates should probably be moved to a Build-Template script as well. Alternatively, we can keep it here for now and define a more general approach to solve this consistently. I'm fine with anything. Just wanted to share that to see what your thoughts are.
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.
Well, if we move templates and AOE to a different script, why don't we move workbooks and Bicep registry modules as well? Maybe each toolkit component type should have its own build script following some naming pattern and then we had the Build-Toolkit script calling all of them, provided the component directory (templates, workbooks, aoe, etc.) had a build script... But I'd keep it as is for now. I am adding a TODO to review the logic. If you prefer, I can open an issue for this.
Copy-Item "$path/azuredeploy.json" "$deployDir/$($path.Name)-latest.json" | ||
|
||
$packageManifestPath = "$path/package-manifest.json" | ||
if (Test-Path $packageManifestPath) |
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.
nit: Would it be better to define a fallback manifest instead of just falling back to the previous logic? That way, we always work with a manifest, we just define a default one. I'm okay to not do that or maybe just add a TODO comment. Just a thought that crossed my mind.
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 agree. I was about to include this change, but then I thought: where do we define the fallback manifest? Inline or as a file placed somewhere in the src structure? As I didn't want to make this decision now, I am leaving a TODO comment for now.
π οΈ Description
Changed build, package and publish scripts to include the required assets for the Optimization Engine release and deployment process. The
docs/deploy
folder includes files that are just copies coming from thesrc/optimization-engine
folder.Also included minor bug fixes in workbooks and runbooks.
π Checklist
π¬ How did you test this change?
πββοΈ Do any of the following that apply?
π Did you update
docs/changelog.md
?π Did you update documentation?