* Run publish on failed or succeeded
* Expand agent os string detection
* Check agent job status env var for artifact name detection
* Add sbomEnabled flag to publish template
* Fix image and artifact name conditional
* Add 1es changes for job/matrix generation and publish
* Use more flexible pool filter for prev/next pool matches
* consolidate displayname definition
* use linux pool variables for generate matrix job
* Fix publish artifact
* Use single publish task for publish artifact
* Support resolving environment variable references in matrix config
* Improve type and null handling
* Fix reference bug
* Change behavior on missing env vars to throw
* Update repo URLs and requirements file path for cache job
* Fixing bug in script
* Update yaml to match PPE and PROD database names and repo branches
* Use git owner uppercase to match DB key in PPE and PROD
* Update both PPE and PROD in different steps using the same pipeline
* Script
* Pipeline
* Change env var names
* Fix the path of the script in the yml file
* Fix script path
* Move script to eng/scripts
* Rename script file
* Update script path
* Update repo-structure-cache-job.yml
* Update repo-structure-cache-job.yml
* Use pat instead of token kv
* Use correct pat kv var
* Comments addressed for the script
* Addressing comments in pipeline yaml file
* Fix bug in args name
* Rename folders and move script
* Uncoment code
* Prepare-Release.ps1: Make dateTime.ToString("MM/dd/yyyy") to work on exotic set-ups
On my machine, I experimented with the registry, and the worst part is that I don't remember/know how to reset it back.
The work items that script produces, do have datetimes for the upcoming releases in the `MM-dd-yyyy` format, and then I have to correct them by hand.
`dateTime.ToString("MM/dd/yyyy")` does produce the date in the format of `MM-dd-yyyy` on my machine. This also happens if I write a corresponding .NET app.
The fix that I am proposing makes it work on my specific setup and hopefully breaks no one else. I understand if you are hesitant to take it. Let me know, I'll see how I can restore my setting.
But on the other hand, I don't think it makes anything worse, it only makes things more robust, so maybe take it?
* Use [CultureInfo]::InvarialtCulture
* Fix role assignment for user auth
* PR fb
* Apply suggestions from code review
Co-authored-by: Heath Stewart <heaths@outlook.com>
---------
Co-authored-by: Heath Stewart <heaths@outlook.com>
* Correct the name of JS package folder
* Uncomment the package verification
* Logging more info for troubleshooting
* Get sdkType and directory from the package info
* Add ConflictedFile to git-helpers.ps1, add git-helpers.tests.ps1 to exercise basic functionality.
* Add `resolve-asset-conflict.ps1` a script that can autoresolve an assets.json file.
---------
Co-authored-by: Scott Beddall (from Dev Box) <scbedd@microsoft.com>
Co-authored-by: Scott Beddall <45376673+scbedd@users.noreply.github.com>
Co-authored-by: Ben Broderick Phillips <bebroder@microsoft.com>
* Added script and pipeline for spec location validation
SDK release pipeline would run this validation to ensure the spec comes from
the main branch of Azure/azure-rest-api-specs repo
* Update parameter
* Use github rest api to validate commit
* Added token parameter
* Support more yaml cases and other languages
* Removed the default setting in yaml template
* Only validate in case of GA package
* Follow APIView to retrieve package version for verification
* Get github token from env variable
* Removed obsolete parameter
* check for the presence of a compatible powershell. ensure that we always return a list of tags
* allow the script to require pshell6+
* remove the en-us from the link
* Revert "Add extra handling for errors during clean-up"
This reverts commit 3eb8cb7329.
* Skip container clean-up for file storage accounts as it has none