The migration tool and doc examples all use the unofficial one ecks dee
Also create a dupe of the PR pipeline so we can migrate main to that file once it is checked in and then delete the other one to rename it to a more descriptive name.
The migration tool and doc examples all use the unofficial one ecks dee
Also create a dupe of the PR pipeline so we can migrate main to that file once it is checked in and then delete the other one to rename it to a more descriptive name.
* Migrate pipeline to 1es
* Clean up changes made from migration tool
* Separate pipeline out into many yaml files so we can have 2 pipelines without code duplication
due to new internal requirement
* remove unncessary pipeline backup
* Remove pipeline from 1es for public as it is not going to be added to the organization in public
* Update yaml loop logic
Remove devcontainer as it is out of compliance and not used by anyone
* fix mappping by adding body to the loop with indentation:
* add a 1es repository
* Create a separate 1es pipeline
* use self to search in the correct repository
* migrate to self on 1es
* use folder name pipeline-templates over templates
* use yaml over yml
* temporarily move jobs into one os
* split pools
* Move the loop to out of the job
* move the task into steps instead of a job as u cant do a job in a job
* remove template keyword
* dont call steps template in job outside of steps
* use yaml instead of yml
* add sdl
* use unique names for jobs
* use _ instead of space
* Use azure pipelines name to conform to style
* give image to each parameter
* make it 1 os for 1 os job and use different pool
* Call pool explicyk
* try to fix names
* Use different source for mac instead of 1es
* Update get-func-name
* Update public PR pipeline
* use public pool as thats what the name param is for
* give image name instead of vmimage as it snot used
* try to switch to a better pool
* try using internal pool on public as external is not available
* Publish logs to os specific folder
* condition steps so they are skipped if not needed per os
* dont care if it succeeded
* add paran
* remove paran
* use parameter pools instead of agent os
* move to 7.0 instead of 6 bc six is broken in the cache online maybe
* switch to 1es pool
* try using public pool
* See if mac pipeline has a mirror in svc
* use image names from open
* Use vm image in the image
* Use vm image in the image
* update vm image
* try to condition the pool
* code cleanup now that everything was working
* fix whitespace
* Update vscode-test
* Update vscode-test to the new name
* respond to most pr feedback
* rename the file as I cannot change the pipeline name while its in main maybe
When users enter manual versions we will see a lot more bad version strings which currently are reported as a failure for us to acquire. We dont want to pollute the telemetry with bad data for failure analysis.
When doing this change, I also improved logging for powershell and noticed some cancellation errors are still counted as failure due to some bugs like throwing a new error instead of bumping up the error, and some places throw the event and others throw the error inside of the event, We need to update the code to do both, although it is probably better to migrate all code to one system, that is a big change I dont want to do right now
When we add activation on startup finished we encountered a new bug with the test process that has existed for many years
it will activate twice and the extension will be in a bad state. we need to allow manual activation to inject the correct mock classes into the extension and prevent it from activating on startupfinished under test.
if we fail to update we are probably still fine
but update is sometimes the first command to be executed
if it is the first and fails, then we will continue with the master process being dead
while thinking it is alive
Noah Gilson
Noah Gilson
Noah Gilson
annie