2020-11-26 06:18:25 -06:00
# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml
trigger :
2021-01-26 17:42:04 -06:00
branches :
include :
- master
2022-10-27 04:36:43 -05:00
- 202 ? ? ?
2021-02-03 12:17:13 -06:00
paths :
exclude :
- .github
2020-11-26 06:18:25 -06:00
2021-01-07 21:50:11 -06:00
pr :
2021-02-03 12:17:13 -06:00
branches :
include :
- master
2022-10-27 04:36:43 -05:00
- 202 ? ? ?
2021-02-03 12:17:13 -06:00
paths :
exclude :
- .github
2020-11-26 06:18:25 -06:00
2021-01-07 21:50:11 -06:00
name : $(TeamProject)_$(Build.DefinitionName)_$(SourceBranchName)_$(Date:yyyyMMdd)$(Rev:.r)
2020-11-26 06:18:25 -06:00
2021-01-07 21:50:11 -06:00
resources :
repositories :
- repository : sonic-mgmt
type : github
2022-07-28 01:54:25 -05:00
name : sonic-net/sonic-mgmt
endpoint : sonic-net
2022-04-01 18:48:44 -05:00
- repository : buildimage
type : github
2022-08-02 03:24:14 -05:00
name : sonic-net/sonic-buildimage
endpoint : sonic-net
2022-04-01 18:48:44 -05:00
ref : master
2021-01-07 21:50:11 -06:00
2022-03-23 09:36:53 -05:00
variables :
2022-07-13 04:30:23 -05:00
- template : .azure-pipelines/azure-pipelines-repd-build-variables.yml@buildimage
2022-08-28 22:26:15 -05:00
- template : .azure-pipelines/template-variables.yml@buildimage
2022-03-23 09:36:53 -05:00
- name : CACHE_MODE
2022-05-05 18:21:30 -05:00
value : rcache
- name : ENABLE_FIPS
value : y
2022-03-23 09:36:53 -05:00
2021-01-07 21:50:11 -06:00
stages :
2022-03-23 09:36:53 -05:00
- stage : BuildVS
2021-01-07 21:50:11 -06:00
pool : sonicbld
jobs :
2021-04-19 20:15:00 -05:00
- template : .azure-pipelines/azure-pipelines-build.yml
2021-02-12 01:34:05 -06:00
parameters :
2022-07-18 19:42:17 -05:00
buildOptions : 'USERNAME=admin SONIC_BUILD_JOBS=$(nproc) BUILD_MULTIASIC_KVM=y ${{ variables.VERSION_CONTROL_OPTIONS }}'
[ci] Fix the boolean value case sensitive issue in Azure Pipelines (#7399)
Why I did it
Fix the boolean value case sensitive issue in Azure Pipelines
When passing parameters to a template, the "true" or "false" will have case sensitive issue, it should be a type casting issue.
To fix it, we change the true/false to yes/no, to escape the trap.
Support to override the job groups in the template, so PR build has chance to use different build parameters, only build simple targets. For example, for broadcom, we only build target/sonic-broadcom.bin, the other images, such as swi, debug bin, etc, will not be built.
2021-04-22 20:26:16 -05:00
jobGroups :
- name : vs
2022-03-23 09:36:53 -05:00
- stage : Build
pool : sonicbld
2023-03-02 20:45:12 -06:00
variables :
INSTALL_DEBUG_TOOLS : y
2022-03-23 09:36:53 -05:00
dependsOn : [ ]
jobs :
- template : .azure-pipelines/azure-pipelines-build.yml
parameters :
buildOptions : 'USERNAME=admin SONIC_BUILD_JOBS=$(nproc) ${{ variables.VERSION_CONTROL_OPTIONS }}'
jobGroups :
[ci] Fix the boolean value case sensitive issue in Azure Pipelines (#7399)
Why I did it
Fix the boolean value case sensitive issue in Azure Pipelines
When passing parameters to a template, the "true" or "false" will have case sensitive issue, it should be a type casting issue.
To fix it, we change the true/false to yes/no, to escape the trap.
Support to override the job groups in the template, so PR build has chance to use different build parameters, only build simple targets. For example, for broadcom, we only build target/sonic-broadcom.bin, the other images, such as swi, debug bin, etc, will not be built.
2021-04-22 20:26:16 -05:00
- name : broadcom
2021-05-05 17:42:33 -05:00
variables :
swi_image : yes
[ci] Fix the boolean value case sensitive issue in Azure Pipelines (#7399)
Why I did it
Fix the boolean value case sensitive issue in Azure Pipelines
When passing parameters to a template, the "true" or "false" will have case sensitive issue, it should be a type casting issue.
To fix it, we change the true/false to yes/no, to escape the trap.
Support to override the job groups in the template, so PR build has chance to use different build parameters, only build simple targets. For example, for broadcom, we only build target/sonic-broadcom.bin, the other images, such as swi, debug bin, etc, will not be built.
2021-04-22 20:26:16 -05:00
- name : mellanox
2023-06-07 20:40:20 -05:00
- name : marvell-arm64
pool : sonicbld-arm64
variables :
PLATFORM_ARCH : arm64
2022-03-23 09:36:53 -05:00
- name : marvell-armhf
pool : sonicbld-armhf
timeoutInMinutes : 1200
variables :
PLATFORM_ARCH : armhf
2021-01-07 21:50:11 -06:00
- stage : Test
2022-03-23 09:36:53 -05:00
dependsOn : BuildVS
2022-10-18 23:26:50 -05:00
condition : and(succeeded(), and(ne(stageDependencies.BuildVS.outputs['vs.SetVar.SKIP_VSTEST'], 'YES'), in(dependencies.BuildVS.result, 'Succeeded', 'SucceededWithIssues')))
2021-01-07 21:50:11 -06:00
variables :
2023-06-01 21:39:04 -05:00
- group : SONiC-Elastictest
2021-01-07 21:50:11 -06:00
- name : inventory
value : veos_vtb
- name : testbed_file
value : vtestbed.csv
2022-09-02 17:53:54 -05:00
# For every test job:
# continueOnError: false means it's a required test job and will block merge if it fails
# continueOnError: true means it's an optional test job and will not block merge even though it fails(unless a required test job depends on its result)
2021-01-07 21:50:11 -06:00
jobs :
2021-01-24 23:01:19 -06:00
- job :
2021-01-31 21:47:10 -06:00
pool : sonictest
2021-01-24 23:01:19 -06:00
displayName : "vstest"
timeoutInMinutes : 60
steps :
2022-10-20 00:06:10 -05:00
- template : .azure-pipelines/cleanup.yml
2021-01-24 23:01:19 -06:00
- checkout : self
2021-01-31 21:47:10 -06:00
clean : true
2021-01-24 23:01:19 -06:00
submodules : recursive
displayName : 'Checkout code'
2022-10-25 02:45:01 -05:00
- script : |
sudo rm -rf ../target
sudo rm -rf ../*.deb
displayName : "Cleanup"
2021-01-24 23:01:19 -06:00
- task : DownloadPipelineArtifact@2
inputs :
source : specific
project : build
pipeline : 9
2021-08-21 16:30:04 -05:00
artifact : sonic-swss-common.amd64.ubuntu20_04
2021-01-24 23:01:19 -06:00
runVersion : 'latestFromBranch'
runBranch : 'refs/heads/master'
displayName : "Download sonic swss common deb packages"
2021-01-27 21:58:58 -06:00
- task : DownloadPipelineArtifact@2
inputs :
2021-02-12 01:34:05 -06:00
artifact : sonic-buildimage.vs
displayName : "Download sonic-buildimage.vs artifact"
2021-01-27 21:58:58 -06:00
2021-01-24 23:01:19 -06:00
- script : |
2021-01-27 21:58:58 -06:00
set -x
2022-09-30 02:56:46 -05:00
sudo apt-get update
sudo apt-get install libyang0.16 -y
2021-08-21 16:30:04 -05:00
sudo dpkg -i --force-confask,confnew ../libswsscommon_1.0.0_amd64.deb
sudo dpkg -i ../python3-swsscommon_1.0.0_amd64.deb
2021-01-27 21:58:58 -06:00
sudo docker load -i ../target/docker-sonic-vs.gz
2021-01-24 23:01:19 -06:00
docker tag docker-sonic-vs:latest docker-sonic-vs:$(Build.BuildNumber)
username=$(id -un)
trap "docker ps; docker images; ip netns list; \
docker rmi docker-sonic-vs:$(Build.BuildNumber); \
ip netns list | grep -E [-]srv[0-9]+ | awk '{print $1}' | xargs -I {} sudo ip netns delete {}; \
2021-01-25 21:05:01 -06:00
sudo chown -R ${username}.${username} .; \
sudo chown -R ${username}.${username} $(System.DefaultWorkingDirectory)" EXIT
2021-01-24 23:01:19 -06:00
pushd platform/vs/tests
2021-01-27 21:58:58 -06:00
sudo py.test -v --junitxml=tr.xml --imgname=docker-sonic-vs:$(Build.BuildNumber)
2021-01-24 23:01:19 -06:00
displayName : "Run vs tests"
- task : PublishTestResults@2
inputs :
testResultsFiles : '**/tr.xml'
testRunTitle : vstest
2023-06-02 03:33:30 -05:00
- job : t0_elastictest
2023-03-07 07:14:04 -06:00
pool : ubuntu-20.04
2023-06-02 03:33:30 -05:00
displayName : "kvmtest-t0 by Elastictest"
[TestbedV2][master] Remove timeout in each step. (#12915)
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
Why I did it
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
How I did it
Remove the timeout parameter in each step, and control the timeout outside in each job.
How to verify it
Set the timeout of one job to 4 hours, and when timeout happens, azure pipeline will cancel this job.
2022-12-04 00:30:03 -06:00
timeoutInMinutes : 240
2022-10-19 00:33:17 -05:00
continueOnError : false
steps :
- template : .azure-pipelines/run-test-scheduler-template.yml
parameters :
TOPOLOGY : t0
2022-11-30 08:36:55 -06:00
MIN_WORKER : $(T0_INSTANCE_NUM)
MAX_WORKER : $(T0_INSTANCE_NUM)
2022-10-19 00:33:17 -05:00
2023-06-02 03:33:30 -05:00
- job : t0_2vlans_elastictest
2023-03-07 07:14:04 -06:00
pool : ubuntu-20.04
2023-06-02 03:33:30 -05:00
displayName : "kvmtest-t0-2vlans by Elastictest"
[TestbedV2][master] Remove timeout in each step. (#12915)
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
Why I did it
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
How I did it
Remove the timeout parameter in each step, and control the timeout outside in each job.
How to verify it
Set the timeout of one job to 4 hours, and when timeout happens, azure pipeline will cancel this job.
2022-12-04 00:30:03 -06:00
timeoutInMinutes : 240
2022-10-19 00:33:17 -05:00
continueOnError : false
steps :
- template : .azure-pipelines/run-test-scheduler-template.yml
parameters :
TOPOLOGY : t0
TEST_SET : t0-2vlans
2022-11-30 08:36:55 -06:00
MIN_WORKER : $(T0_2VLANS_INSTANCE_NUM)
MAX_WORKER : $(T0_2VLANS_INSTANCE_NUM)
2022-10-19 00:33:17 -05:00
DEPLOY_MG_EXTRA_PARAMS : "-e vlan_config=two_vlan_a"
2023-06-02 03:33:30 -05:00
- job : t1_lag_elastictest
2023-03-07 07:14:04 -06:00
pool : ubuntu-20.04
2023-06-02 03:33:30 -05:00
displayName : "kvmtest-t1-lag by Elastictest"
[TestbedV2][master] Remove timeout in each step. (#12915)
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
Why I did it
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
How I did it
Remove the timeout parameter in each step, and control the timeout outside in each job.
How to verify it
Set the timeout of one job to 4 hours, and when timeout happens, azure pipeline will cancel this job.
2022-12-04 00:30:03 -06:00
timeoutInMinutes : 240
2022-10-19 00:33:17 -05:00
continueOnError : false
steps :
- template : .azure-pipelines/run-test-scheduler-template.yml
parameters :
TOPOLOGY : t1-lag
2022-11-30 08:36:55 -06:00
MIN_WORKER : $(T1_LAG_INSTANCE_NUM)
MAX_WORKER : $(T1_LAG_INSTANCE_NUM)
2022-10-19 00:33:17 -05:00
2023-06-02 03:33:30 -05:00
- job : multi_asic_elastictest
displayName : "kvmtest-multi-asic-t1-lag by Elastictest"
2023-03-07 07:14:04 -06:00
pool : ubuntu-20.04
[TestbedV2][master] Remove timeout in each step. (#12915)
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
Why I did it
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
How I did it
Remove the timeout parameter in each step, and control the timeout outside in each job.
How to verify it
Set the timeout of one job to 4 hours, and when timeout happens, azure pipeline will cancel this job.
2022-12-04 00:30:03 -06:00
timeoutInMinutes : 240
2022-12-05 20:19:54 -06:00
continueOnError : false
2022-11-10 20:54:37 -06:00
steps :
- template : .azure-pipelines/run-test-scheduler-template.yml
parameters :
TOPOLOGY : t1-8-lag
TEST_SET : multi-asic-t1-lag
2022-11-30 08:36:55 -06:00
MIN_WORKER : $(MULTI_ASIC_INSTANCE_NUM)
MAX_WORKER : $(MULTI_ASIC_INSTANCE_NUM)
2022-11-10 20:54:37 -06:00
NUM_ASIC : 4
2023-06-02 03:33:30 -05:00
- job : dualtor_elastictest
2023-03-07 07:14:04 -06:00
pool : ubuntu-20.04
2023-06-02 03:33:30 -05:00
displayName : "kvmtest-dualtor-t0 by Elastictest"
[TestbedV2][master] Remove timeout in each step. (#12915)
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
Why I did it
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
How I did it
Remove the timeout parameter in each step, and control the timeout outside in each job.
How to verify it
Set the timeout of one job to 4 hours, and when timeout happens, azure pipeline will cancel this job.
2022-12-04 00:30:03 -06:00
timeoutInMinutes : 240
2022-11-07 05:48:06 -06:00
continueOnError : false
steps :
- template : .azure-pipelines/run-test-scheduler-template.yml
parameters :
TOPOLOGY : dualtor
2022-11-30 08:36:55 -06:00
MIN_WORKER : $(T0_DUALTOR_INSTANCE_NUM)
MAX_WORKER : $(T0_DUALTOR_INSTANCE_NUM)
2022-11-07 05:48:06 -06:00
COMMON_EXTRA_PARAMS : "--disable_loganalyzer "
2022-11-10 01:27:31 -06:00
2023-06-02 03:33:30 -05:00
- job : sonic_t0_elastictest
displayName : "kvmtest-t0-sonic by Elastictest"
2023-03-07 07:14:04 -06:00
pool : ubuntu-20.04
[TestbedV2][master] Remove timeout in each step. (#12915)
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
Why I did it
Previously, we set timeout in each step such as Lock testbed, Prepare testbed, Run test and KVM dump. When some issue suck like retry happens in one step, it will cause timeout error, but actually, it only needs more time to success. In this pr, we remove the timeout limit in each step and control the timeout outside in each job. When the job runs more than four hours, it will be cancelled.
How I did it
Remove the timeout parameter in each step, and control the timeout outside in each job.
How to verify it
Set the timeout of one job to 4 hours, and when timeout happens, azure pipeline will cancel this job.
2022-12-04 00:30:03 -06:00
timeoutInMinutes : 240
2022-12-05 20:19:54 -06:00
continueOnError : false
2022-11-10 01:27:31 -06:00
steps :
- template : .azure-pipelines/run-test-scheduler-template.yml
parameters :
TOPOLOGY : t0-64-32
2022-11-30 08:36:55 -06:00
MIN_WORKER : $(T0_SONIC_INSTANCE_NUM)
MAX_WORKER : $(T0_SONIC_INSTANCE_NUM)
2022-11-10 01:27:31 -06:00
TEST_SET : t0-sonic
2023-06-26 22:02:06 -05:00
COMMON_EXTRA_PARAMS : "--neighbor_type=sonic "
2022-11-10 01:27:31 -06:00
VM_TYPE : vsonic
2022-11-20 20:34:23 -06:00
2023-06-02 03:33:30 -05:00
- job : wan_elastictest
displayName : "kvmtest-wan by Elastictest"
2023-03-07 07:14:04 -06:00
pool : ubuntu-20.04
2022-12-05 20:19:54 -06:00
timeoutInMinutes : 240
continueOnError : false
2022-11-20 20:34:23 -06:00
steps :
- template : .azure-pipelines/run-test-scheduler-template.yml
parameters :
TOPOLOGY : wan-pub
2022-11-30 08:36:55 -06:00
MIN_WORKER : $(WAN_INSTANCE_NUM)
MAX_WORKER : $(WAN_INSTANCE_NUM)
2022-11-20 20:34:23 -06:00
COMMON_EXTRA_PARAMS : "--skip_sanity "