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
2023-08-01 03:18:35 -05:00
ref : master
2022-07-28 01:54:25 -05:00
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 :
2023-11-30 15:52:54 -06:00
buildOptions : 'USERNAME=admin SONIC_BUILD_JOBS=$(nproc) BUILD_MULTIASIC_KVM=y INCLUDE_DHCP_SERVER=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
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-08-01 08:03:49 -05:00
variables :
dbg_image : yes
docker_syncd_rpc_image : yes
platform_rpc : mlnx
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-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
2023-09-11 23:54:40 -05:00
- script : |
sudo src/sonic-swss-common/.azure-pipelines/build_and_install_module.sh
displayName : "Install kernel modules"
2021-01-24 23:01:19 -06:00
- script : |
2022-09-30 02:56:46 -05:00
sudo apt-get update
2023-06-27 16:40:20 -05:00
sudo apt-get install -y make libtool m4 autoconf dh-exec debhelper cmake pkg-config \
2023-09-23 02:03:36 -05:00
libhiredis-dev libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libnl-nf-3-dev swig \
2023-06-27 16:40:20 -05:00
libpython2.7-dev libboost-dev libboost-serialization-dev uuid-dev libzmq5 libzmq3-dev python3-pip \
2023-09-23 02:03:36 -05:00
cmake libgtest-dev libgmock-dev libyang-dev nlohmann-json3-dev
2023-06-27 16:40:20 -05:00
sudo pip3 install pytest
cd src/sonic-swss-common
./autogen.sh
dpkg-buildpackage -rfakeroot -us -uc -b -j$(nproc)
sudo dpkg -i --force-confask,confnew ../libswsscommon_*.deb
sudo dpkg -i ../python3-swsscommon_*.deb
displayName : "Compile sonic swss common"
- script : |
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 :
2023-08-01 03:18:35 -05:00
- template : .azure-pipelines/run-test-elastictest-template.yml@sonic-mgmt
2022-10-19 00:33:17 -05:00
parameters :
TOPOLOGY : t0
2022-11-30 08:36:55 -06:00
MIN_WORKER : $(T0_INSTANCE_NUM)
MAX_WORKER : $(T0_INSTANCE_NUM)
2024-01-21 23:04:16 -06:00
MGMT_BRANCH : "202311"
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 :
2023-08-01 03:18:35 -05:00
- template : .azure-pipelines/run-test-elastictest-template.yml@sonic-mgmt
2022-10-19 00:33:17 -05:00
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)
2024-01-21 23:04:16 -06:00
MGMT_BRANCH : "202311"
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 :
2023-08-01 03:18:35 -05:00
- template : .azure-pipelines/run-test-elastictest-template.yml@sonic-mgmt
2022-10-19 00:33:17 -05:00
parameters :
TOPOLOGY : t1-lag
2022-11-30 08:36:55 -06:00
MIN_WORKER : $(T1_LAG_INSTANCE_NUM)
MAX_WORKER : $(T1_LAG_INSTANCE_NUM)
2024-01-21 23:04:16 -06:00
MGMT_BRANCH : "202311"
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 :
2023-08-01 03:18:35 -05:00
- template : .azure-pipelines/run-test-elastictest-template.yml@sonic-mgmt
2022-11-10 20:54:37 -06:00
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
2024-01-21 23:04:16 -06:00
MGMT_BRANCH : "202311"
2022-11-10 20:54:37 -06:00
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 :
2023-08-01 03:18:35 -05:00
- template : .azure-pipelines/run-test-elastictest-template.yml@sonic-mgmt
2022-11-07 05:48:06 -06:00
parameters :
TOPOLOGY : dualtor
2022-11-30 08:36:55 -06:00
MIN_WORKER : $(T0_DUALTOR_INSTANCE_NUM)
MAX_WORKER : $(T0_DUALTOR_INSTANCE_NUM)
2024-01-21 23:04:16 -06:00
MGMT_BRANCH : "202311"
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 :
2023-08-01 03:18:35 -05:00
- template : .azure-pipelines/run-test-elastictest-template.yml@sonic-mgmt
2022-11-10 01:27:31 -06:00
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
2024-01-21 23:04:16 -06:00
MGMT_BRANCH : "202311"
2023-06-26 22:01:41 -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
2024-02-05 12:07:20 -06:00
# - job: dpu_elastictest
# displayName: "kvmtest-dpu by Elastictest"
# timeoutInMinutes: 240
# continueOnError: false
# pool: ubuntu-20.04
# steps:
# - template: .azure-pipelines/run-test-elastictest-template.yml@sonic-mgmt
# parameters:
# TOPOLOGY: dpu
# MIN_WORKER: $(T0_SONIC_INSTANCE_NUM)
# MAX_WORKER: $(T0_SONIC_INSTANCE_NUM)
# MGMT_BRANCH: "202311"
2023-10-26 00:34:49 -05:00
2023-07-09 21:47:40 -05:00
# - job: wan_elastictest
# displayName: "kvmtest-wan by Elastictest"
# pool: ubuntu-20.04
# timeoutInMinutes: 240
# continueOnError: false
# steps:
# - template: .azure-pipelines/run-test-scheduler-template.yml
# parameters:
# TOPOLOGY: wan-pub
# MIN_WORKER: $(WAN_INSTANCE_NUM)
# MAX_WORKER: $(WAN_INSTANCE_NUM)
# COMMON_EXTRA_PARAMS: "--skip_sanity "