[Issue] Publish nightly extension builds
- Dominant language
- Go
- Stars
- 569
- Forks
- 364
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 136
Description
Two work streams here - the immediate work, and work we'll need as we run long-term:
## First-pass
- [x] Publishing releases should go to the Azure Storage blob account
- [x] Re-use the existing build pipelines for extensions, just iterate and loop
- [x] For setting the extension version, we'll use the Build type (ie, manual, scheduled, etc..) to determine if we're going to generate a nightly extension version, rather than just using version.txt.
- New-ReleaseNotesFile.ps1 might need changes to make sure it doesn't error out for a CHANGELOG that's not updated (ie, has a release date).
- [x] (publish-extension.yaml): Publish_Release, should have a condition to check what the conditions are - if it runs it'll require an approval.
- add in a `daily` folder
- delete the _manifest folder.
- [x] Nightly builds should use the trigger for scheduling, and not a schedule block in the YAML itself.
- Only trigger nightly builds on source changes. (@JeffreyCA also loves this!)
## Follow up
- [x] #9178
- [ ] Use git-push-changes.yaml for pushing the extensions changes for the extensions manifest.
- [x] ~~'dev' builds might actually be publishing to the storage account already, but if not, we want to publish to a storage path that contains the version.~~ (moved to https://github.com/Azure/azure-dev/issues/9177)
- [x] #9179
- [ ] [Move the check for the build.reason into the inline powershell script instead of template {else}](https://github.com/Azure/azure-dev/pull/8740#discussion_r3454275164)
- [ ] [Update-NightlyExtensionRegistry.ps1 ergonomics - set default values and doc the parameters](https://github.com/Azure/azure-dev/pull/8740#discussion_r3454331712)
- [x] ~~Cleanup for nightly builds - how long do we keep releases and how do we cleanup old ones?~~ (moved to its own standalone issue: https://github.com/Azure/azure-dev/issues/9177)
- [x] Version numbers for nightly builds - we went with a -nightly.buildnumber but we might want something else (there wasn't any feedback on this from anyone and was just some speculating between @danieljurek and I, going to close this item)
Contributor guide
Assessment
This issue has not been assessed yet.