Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile error in sonic-swss/orchagent/orchdaemon.cpp for 202205 branch #2682

Closed
vmittal-msft opened this issue Feb 27, 2023 · 3 comments · Fixed by #2685
Closed

Compile error in sonic-swss/orchagent/orchdaemon.cpp for 202205 branch #2682

vmittal-msft opened this issue Feb 27, 2023 · 3 comments · Fixed by #2685
Labels

Comments

@vmittal-msft
Copy link
Contributor

vmittal-msft commented Feb 27, 2023

image

This is blocking new PRs - #2618
When i compile locally, it is fine. Only happening in PR Az pipeline.

@saiarcot895
Copy link
Contributor

saiarcot895 commented Feb 27, 2023

Recent runs in sonic-swss-common for the 202205 branch have been failing vstest (the deb packages are built, though). Because of this, azure pipeline is taking the artifacts from the most recent fully successful run, which is prior to sonic-net/sonic-swss-common@16ff689 (which the current version of sonic-swss 202205 branch needs).

There are two options here:

  1. Revert 380f72b from the 202205 branch. This at least removes the dependency of the newer sonic-swss-common build needed to build the current sonic-swss. However, there may still be a vstest failure depending on what is causing the failure.
  2. Allow azure pipeline to get artifacts even from partially successful/failed builds. Note that this may increase the number of pipeline failures for sonic-swss, even though the problem may be elsewhere. I have a draft PR for this at Clean up list of packages to install for pipeline build #2683. (EDIT: Looks like this actually won't work, this setting causes azure pipeline to consider using pipeline runs where everything fails, and when the needed artifact is missing, it errors out.)

@xumia
Copy link
Collaborator

xumia commented Mar 2, 2023

For # 2, it may be a little aggressive to download the artifacts from the failed build. A PR #2685 to build the sonic-swss-common directly in sonic-swss, is it good for it? @saiarcot895 .

@saiarcot895
Copy link
Contributor

Yeah that might be better, particularly if it doesn't take long to build it.

@prsunny prsunny linked a pull request Mar 7, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants