New cd images (ADX support and ARM64)

[tarakby]

Update the node software process after the latest crypto module changes:

1. the crypto module has non-portable code that requires proper cross compilation when building for a different target
2. the crypto module uses CPU's ADX instructions. If the target CPU does not support ADX, such code should be disabled.

In this PR:

• fix a bug in a previous PR (commit) where the empty netgo tag was removed. This fixes the build without netgo.
• rename the build that uses the local script arch and ADX detection to "native build". These builds assume the image is built and run on the same machine type (arch and cpu properties). This is the case of CI tests and integration tests for instance.
• add new images to build production images with and without ADX code:
  • with ADX code: can only run on a machine with ADX support, this is the default case, and it offers optimal performance.
  • without ADX code: uses portable code and can run on all machines. The build requires adding a CGO flag, passed as an argument to Dockerfile. It offers slower performance.
• add a new image for arm64 cross build. The build requires specifying the cross-compiler in CC. CC is passed to the Dockerfile as an argument.
• add all new images build to cd.yml and add a step to install the cross-compilation tools (works only on Debian)
• update builds.yml to use the new commands.
• image names in Makefile use IMAGE_TAG only (which is derived from the short commits in most cases)

These are the images built in cd.yml (assumed to run on amd64):

• with ADX code
• with ADX code and without netgo.
• without ADX code and without netgo.
• arm64 images
  ( without ADX code and with netgo was skipped for now but can be added if needed. With the current PR, if we disable ADX, netgo has to be disabled too. This assumes that there are no machines that cannot run images with netgo disabled)
  builds.yml can generate the same images but the arm64 ones, because of the limitation of number of input boxes in githhub workflows.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (f0b7f2a) 55.61% compared to head (12d4b6c) 55.58%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5254      +/-   ##
==========================================
- Coverage   55.61%   55.58%   -0.03%     
==========================================
  Files        1002     1002              
  Lines       96600    96600              
==========================================
- Hits        53720    53695      -25     
- Misses      38820    38844      +24     
- Partials     4060     4061       +1     

Flag	Coverage Δ
unittests	55.58% <ø> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tarakby]

needed for the arm cross-build

[tarakby]

native builds detect whether the current machine supports ADX using crypto_adx_flag.mk

[tarakby]

Optimal case (with ADX and with netgo) - this is called in CD.

Note that the image has the same "tag" as the native builds. Native builds (locally or CI) are not run in CD.

[peterargue]

so the difference between this an docker-native-build-collection is that native allows overriding ADX while this doesn't?

[tarakby]

This target hardcodes the arguments for a specific target (ideally I would want to hardcode GOARCH too, but left it in case we want to call it on ARM machines too).

docker-native-build-... set the arguments based on the host (detect ADX support, set ARCH)

[tarakby]

For better clarity and consistency, I hardcoded amd64 for production targets that are not natively built and not meant for arm d3b99bd (though I can revert it if needed)

[peterargue]

so the difference between this an docker-native-build-collection is that native allows overriding ADX while this doesn't?

[sjonpaulbrown]

@tarakby, using this branch, could you please run all of the workflows being modified so that we can verify the execution?

Also, as a general comment, I think we will need to update the following lines in the build workflow to use the new make targets

• https://github.com/onflow/flow-go/blob/master/.github/workflows/builds.yml#L119
• https://github.com/onflow/flow-go/blob/master/.github/workflows/builds.yml#L127

[sjonpaulbrown]

If the targets are changing, the following workflow will also need to be updated to align with the target changes.

This will need to be updated separately, but this will break BN2 until the workflow is updated.

[peterargue]

Thanks for adding support for ARM builds and unravelling our complex mess of a makefile.

I'm a little confused by all make target names, but I think the changes are correct, so I don't want to hold this up this PR over naming.

We should circle back and refactor the build system soon. It's become pretty complex.

[tarakby]

@sjonpaulbrown, the PR is now ready.

• cd.yml was tested in this workflow
• builds.yml was tested in this workflow

[tarakby]

I'm a little confused by all make target names, but I think the changes are correct, so I don't want to hold this up this PR over naming.
We should circle back and refactor the build system soon. It's become pretty complex.

Agree, the build system could be made simpler.

[sjonpaulbrown]

Altering this tag name could impact partner automation. We will want to work with @vishalchangrani to ensure that the partners who rely on this know the image tag is changing.