Install sonic yangs during pipeline build #124
Conversation
sachinholla
force-pushed
the
azp_sonicyang
branch
from
11d9dd6 to
b176ee4
Compare
sachinholla
force-pushed
the
azp_sonicyang
branch
from
b176ee4 to
1b691ea
Compare
azure-pipelines.yml
Outdated
| patterns: | | ||
| target/debs/buster/libyang*.deb | ||
| target/python-wheels/bullseye/sonic_yang_models*.whl |
There was a problem hiding this comment.
Can you learn a Debian distribution on the fly instead?
There was a problem hiding this comment.
Do you have any references? I could not find another such instance.
Not sure how to determine it generically. Did not find any settings in debian/control or any other setting files under sonic-mgmt-framework repo. As per my understanding the target debian version is chosen buy the docker build rules file, by adding the docker image file name to different makefile variables -- like here and here. These docker makefiles are not used during pipeline builds. In fact we do not download sonic-buildimage code as well. Even if we donwload we cannot invoke these makefiles directly. Also, the code pattern is not generic enough to grep & determine the debian version.
* Download & install sonic_yang_models.whl before build * Download source code and artifacts for the build branch only * Download from pipeline 142, which runs on all branches
sachinholla
force-pushed
the
azp_sonicyang
branch
from
1b691ea to
48576ac
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
azure-pipelines.yml
Outdated
|
|
||
| - task: DownloadPipelineArtifact@2 | ||
| inputs: | ||
| source: specific | ||
| project: build | ||
| pipeline: 1 | ||
| pipeline: 142 |
There was a problem hiding this comment.
You can dynamically retrieve the pipeline ID using the Azure DevOps CLI or REST API. Then, set the pipeline ID as a variable to avoid hardcoding it in your configuration.
There was a problem hiding this comment.
This is just a declarative yaml file, cannot run commands.. I just followed the existing logic where pipeline id 1 was hardcoded.. There is no dynamic pipeline requirement here -- idea is to download yang & libyang from the latest official vs build, which is pipeline 142. Anyway tried changing it to the pipeline name and it worked.
There was a problem hiding this comment.
The Azure pipeline YAML configuration allows you to dynamically retrieve and use the pipeline ID to avoid hardcoding it.
e.g.
- script: |
PIPELINE_ID=$(curl -k "https://dev.azure.com/mssonic/build/_apis/pipelines?api-version=7.1" | jq -r '.value[] | select(.name=="Azure.sonic-buildimage.official.generic") | .id')
displayName: 'Get Pipeline ID'
- task: DownloadPipelineArtifact@2
inputs:
source: specific
project: build
pipeline: $(PIPELINE_ID)
. . .
There was a problem hiding this comment.
Will the script local variable automatically get exported as pipeline variable?
Anyway, did you check the latest? I have used the pipeline name instead of id.
There was a problem hiding this comment.
Okay, I notice the pipeline id has been replaced with the pipeline name. No hardcoding, which resolves my comment.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Why I did it
Translib now consumes select sonic yangs from
sonic-yang-models.whlduring compile time as well as runtime. Hence pipeline builds needs to install the appropriatesonic_yang_models.whlfor all translib functionalities to be available for testing.Also, the pipeline is always downloading sonic-mgmt-common code and other artifacts from master branch. This may not work if we run the pipeline build on other branches. Pipeline should use artifacts of build branch only.
How I did it
How to verify it
PR build