CLOUDP-295785 - Fix multi-arch builds by migrating away from goreleaser

[MaciejKaras]

Summary

⚠️ Some of the files were moved and this messes up GitHub preview. It's better to review the last commit with all the changes 5eb86a9

Completely removed goreleaser usage in the project. It was preventing us to build multiarch kubect-mongodb plugin binaries. There were also other reasons to drop goreleaser i.e. it was only used to build binaries, nothing else was used, but required us to keep additional, static .goreleaser.yaml that was not compatible with build_info.json.

This PR also improves quite a lot of other things:

• moves building of kubectl-mongodb plugin to a separate evergreen task
• kubectl-mongodb plugin is now only dowloaded when building test image. This means we need to wait with building test image for kubectl-plugin to be available in s3
• promote_kubectl_plugin.py now uses temp_dir instead of hardcoded ./artifacts dir. Previously we couldn't re-run the promotion pipeline if the signatures were already present on the machine: Signature already exists. Displaying proof
• simplified and unified the build_kubectl_plugin.py‎ and download_kubectl_plugin.py scripts
• removed all references to goreleaser
• kubectl-mongodb also pushes binaries to s3 release bucket so they can be used for e2e smoke tests
• kubectl-mongodb is now pushed to staging and released with two new architectures:
  • linux/s390x
  • linux/ppc64le

Proof of Work

Passing CI for PR.

Passing CI for smoke arm on staging scenario (with arm smoke tests enabled)

Passing CI for release scenario (release_kubectl_mongodb_plugin fails on adding assets to GH release, which is expected since there is no release rc-1.3.0)

Checklist

• Have you linked a jira ticket and/or is the ticket in the title?
• Have you checked whether your jira ticket required DOCSP changes?
• Have you added changelog file?
  • use skip-changelog label if not needed
  • refer to Changelog files and Release Notes section in CONTRIBUTING.md for more details

[github-actions]

⚠️ (this preview might not be accurate if the PR is not rebased on current master branch)

MCK 1.6.0 Release Notes

New Features

• MongoDBCommunity: Added support to configure custom cluster domain via newly introduced spec.clusterDomain resource field. If spec.clusterDomain is not set, environment variable CLUSTER_DOMAIN is used as cluster domain. If the environment variable CLUSTER_DOMAIN is also not set, operator falls back to cluster.local as default cluster domain.
• Helm Chart: Introduced two new helm fields operator.podSecurityContext and operator.securityContext that can be used to configure securityContext for Operator deployment through Helm Chart.

Bug Fixes

• Fixed parsing of the customEnvVars Helm value when values contain = characters.

[lucian-tosa]

This is inconsistent. Building and downloading the binary use a one-line bash script, while promoting uses run_python.sh. I personally prefer using run_python directly instead of having many one-line scripts

[MaciejKaras]

I prefer run_python directly as well, but the issue with that is we cannot use our context variables directly in such call. For example having:

binary: scripts/dev/run_python.sh scripts/release/kubectl_mongodb/download_kubectl_plugin.py --build-scenario "${BUILD_SCENARIO}" --version "${OPERATOR_VERSION}" 

... will not work because BUILD_SCENARIO and OPERATOR_VERSION are not exposed in evergreen and only exported when sourcing the .generated/context.env file

[MaciejKaras]

promote_kubectl_plugin.py is using env variables directly in the code and we can call directly from evg. Other python scripts need bash wrapper.

[viveksinghggits]

If this file's content are not changed, can we mention this here for reviewers help. We can mention that it's already in master we are just moving it to diff location.

[viveksinghggits]

I just read the entire file and it looks like we are changing it slightly.

[MaciejKaras]

I've used git mv command and moved the files in the first commit and changed in another, but this didn't help with the GitHub preview :/

[MaciejKaras]

Reviewing only the latest commit helps! 5eb86a9

[viveksinghggits]

is this required because now we have the compressed as well as decompressed file in staging? I am a little sceptical about the idea because it would make things confusing, like we discussed on call.
But if we HAVE to do this, we should add a comment here explaining that.

[viveksinghggits]

Would it be problematic if run tar locally and don't upload copies or artifacts in S3.

[MaciejKaras]

is this required because now we have the compressed as well as decompressed file in staging?

only in release bucket, in staging we still have only decompressed ones.

if we HAVE to do this, we should add a comment here explaining that

yes, we have to put both compressed as well as decompressed files. Compressed are used for release assets backup while uncompressed are used for e2e testing. I wanted to keep the simple logic when calling download_multi_cluster_binary that is used when building test image and not having to decompress binaries, when downloading from release bucket. It's much simpler to just push both flavours.

[viveksinghggits]

should we keep this file for some time, to make sure we can use this to release plugin in case of issues?

[MaciejKaras]

we can always revert it back or copy it from git history. If it is unused then lets not keep it in repo