Enable staging build scenario that was commented out by default

[viveksinghggits]

Summary

The staging build scenario was commented out by default because we have not been using it in our workflows. But after this PR gets merged we will start using the the staging build scenario for kubectl plugin to build and push it to the staging bucket. That's why this PR enables that build scenario.

Proof of Work

Once the PR #320 related to kubectl plugin gets merged the goreleaser artifacts should be pushed to the mongodb-kubernetes-staging/kubectl-mongodb/<commit-sha> path.

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.3.0 Release Notes

Bug Fixes

• This change fixes the current complex and difficult-to-maintain architecture for stateful set containers, which relies on an "agent matrix" to map operator and agent versions which led to a sheer amount of images.
• We solve this by shifting to a 3-container setup. This new design eliminates the need for the operator-version/agent-version matrix by adding one additional container containing all required binaries. This architecture maps to what we already do with the mongodb-database container.
• Fixed an issue where the readiness probe reported the node as ready even when its authentication mechanism was not in sync with the other nodes, potentially causing premature restarts.

Other Changes

• Optional permissions for PersistentVolumeClaim moved to a separate role. When managing the operator with Helm it is possible to disable permissions for PersistentVolumeClaim resources by setting operator.enablePVCResize value to false (true by default). When enabled, previously these permissions were part of the primary operator role. With this change, permissions have a separate role.
• subresourceEnabled Helm value was removed. This setting used to be true by default and made it possible to exclude subresource permissions from the operator role by specifying false as the value. We are removing this configuration option, making the operator roles always have subresource permissions. This setting was introduced as a temporary solution for this OpenShift issue. The issue has since been resolved and the setting is no longer needed.
• We have deliberately not published the container images for OpsManager versions 7.0.16, 8.0.8, 8.0.9 and 8.0.10 due to a bug in the OpsManager which prevents MCK customers to upgrade their OpsManager deployments to those versions.

[nammn]

how can this work? Have we tested this? if is_evg is true, then its always patch already, no?

[Julien-Ben]

When I wrote the infer method I matched our previous code for the usage of env variables. If is_patchis false but is_evg is true, then we are on master.
I'm confused by the above elif tho.
elif is_patch or is_evg seems incorrect

[nammn]

we really need a way to test those things in the ci/e2e outside of requiring to merge to master

[viveksinghggits]

Hi @Julien-Ben,
I was looking at the docs here https://docs.devprod.prod.corp.mongodb.com/evergreen/Reference/Comparison#whats-a-version-or-patch and here and it is not very clear that is_patch is going to be false if the build is run from the master merge. Do you have reference to a documentation that we can use to confirm that is_patch is false in case of builds to master merges.

[Julien-Ben]

I tried to dig as much as I could in the documentation and commented everything in methods (they were moved to constants.py)

Do the following explanations help ? That's the best I could find

def triggered_by_git_tag() -> str | None:
    """
    "triggered_by_git_tag" is the name of the tag that triggered this version, if applicable. It will be None for
    all patches except when tagging a commit on GitHub
    :return: tag name if the build was triggered by a git tag, otherwise None.
    """
    return os.getenv("triggered_by_git_tag")


def is_evg_patch() -> bool:
    """
    A patch build is a version not triggered by a commit to a repository. "is_patch" is passed automatically by Evergreen.
    It either runs tasks on a base commit plus some diff if submitted by the CLI or on a git branch if created by
    a GitHub pull request.
    :return: "true" if the running task is in a patch build, otherwise "false".
    """
    return os.getenv("is_patch", "false").lower() == "true"


def is_running_in_evg() -> bool:
    """
    "RUNNING_IN_EVG" is set by us in evg-private-context
    :return: "true" if the script is running in Evergreen, otherwise "false".
    """
    return os.getenv("RUNNING_IN_EVG", "false").lower() == "true"


def get_version_id() -> str | None:
    """
    Get the version ID from the environment variable. This is typically used for patch builds in the Evergreen CI system.
    It is generated automatically for each task run. For example: `6899b7e35bfaee00077db986` for a manual/PR patch,
    or `mongodb_kubernetes_5c5a3accb47bb411682b8c67f225b61f7ad5a619` for a master merge
    :return: version_id (patch ID) or None if not set
    """
    return os.getenv("version_id")

[nammn]

the code doesn't seem to work semantically, can we have a proof of work?

[viveksinghggits]

the code doesn't seem to work semantically, can we have a proof of work?

I will verify this and update.