Fix cache related mellanox bullseye build failures

[alexrallen]

Why I did it

Mellanox builds were failing intermittently due to the issue_version file and MFT package not building correctly in the Azure pipeline environment (both of these packages were patched to build correctly with bullseye running on the host and buster running on the dockers)

How I did it

Fixed two problems:

1. BLDENV is not passed to the Makefiles so the references to this were replaced with correct logic
2. issue_version was not defined as a target for bullseye and as such was not cached. Altered the build such that it is defined as a target for bullseye (in the case of buster it builds the file, in the case of bullseye it copies from buster)

The previous PR fixing this was reverted as it is no longer necessary for a passing build and was not a long-term fix. #9235

How to verify it

Build on AZP and verify success.

A picture of a cute animal (not mandatory but encouraged)

[qiluo-msft]

buster

Wondering what is the DEPENDS for debian version before buster and after buster? #Closed

[alexrallen]

Can you please elaborate on your question?

This line exists because this only depends on APPLIBS when the build environment is buster (when it is actually generating the issu_version file)

Otherwise it will try to compile the mellanox sdk for bullseye (which it is not ready to do right now)

[qiluo-msft]

Just to double check: you mean issu_version only exists in Buster, Not in Bulleyes and later, not in Stretch and earlier versions?

[qiluo-msft]

Could you explain this change? #Pending

[alexrallen]

Yes, this checks if the target is bullseye or buster by looking at the destination path for the target.

[qiluo-msft]

your code is only check bullseye? How it is different with original code?

[alexrallen]

BLDENV is not exported to Makefiles, thus this was not functioning.

[qiluo-msft]

However I notice is largely used by many other makefile. Is it something missing in build infra?

[qiluo-msft]

Why this rule depends on Debian version? #Pending

[alexrallen]

Not on the debian version but what is currently being built.

If buster is being built it executes the program which exports the contents of the issue_version file in the buster slave docker.

If bullseye is being built it doesn't have access to this utility so it copies from the buster targets (which has already been built) to itself.

We do this so that we have the file available in both the buster and bullseye slave docker at build time and that both targets are correctly recognized by the build system and cached correctly.

[qiluo-msft]

What is the reason of "If bullseye is being built it doesn't have access to this utility"? Any plan to have the utility (what is it?) in future?

I am wondering if you can make this Makefile not depends on any Debian versions, it should work for Buster, and any future Debian versions.

[qiluo-msft]

You assume build order of Buster/Bullseye. Could you be explicit. I understand this PR is a temporary solution, and after SDK support Bullseye, all the Debian version dependency will be removed.

[qiluo-msft]

@xumia Please help check .dep file

[alexrallen]

@qiluo-msft I think it is best if I respond to your commentary altogether as all of these changes are related to each other.

issu_version is simply a file, it is generated at build time using our SDK userspace tools. These userspace tools are primarily installed on the syncd container.

In buster, we were able to also seamlessly install those userspace tools onto the slave docker and generate the issu_version file for inclusion in the host image.

However, there is not a version of these tools that we officially support right now that is compatible with bullseye, so we can no longer install the tools directly onto the bullseye slave docker which is where the host is built.

In order to workaround this, what I am doing here is splitting the issue_version build into two parts:

One is a part that executes inside the buster build environment. This is the environment where we install these user-space tools and actually generate the issu_version file. This behaves identically to how it did prior to bullseye.

The second is the part that executes inside the bullseye build environment. In this environment we cannot directly call the sdk tools in order to generate the file so we need to make a couple changes. One, in the Makefile for issu_version I detect if we are in the bullseye build environment, if we are, then I skip generating the file and instead copy the file from the buster target to the bullseye target. Two, in the mk file which defines the dependencies we define that if we are in the bullseye build environment it does not depend on the SDK tools (because it does not, you see we are only performing a copy operation).

[alexrallen]

Would like to note this is a temporary workaround while Mellanox syncd / sdk / sai packages are upgraded to support bullseye. I have created the following issue to track the removal of these workarounds once this upgrade process is complete.

#9279

@qiluo-msft please let me know if you require anything else.