ci: append amd64 suffix for staging/testing deployment versions

[prashant-shahi]

Summary

• update CI workflows to append amd64 suffix for staging/testing deployment versions

Related Issues / PR's

NA

Screenshots

NA

Affected Areas and Manually Tested Areas

NA

---

Important

Append -amd64 suffix to version strings in CI workflows for staging and testing deployments.

• CI Workflows:
  • Append -amd64 suffix to VERSION in staging-deployment.yaml and testing-deployment.yaml.
  • Ensures version strings reflect architecture for staging and testing deployments.

^{This description was created by for d9a82e2. It will automatically update as commits are pushed.}

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to ebc2ee8 in 1 minute and 41 seconds

More details

• Looked at 24 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 7 drafted comments based on config settings.

1. .github/workflows/staging-deployment.yaml:53

• Draft comment:
  This VERSION suffix export is duplicated from the testing deployment workflow. Consider extracting this common logic to be reused.

• VERSION suffix export (testing-deployment.yaml)

• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
  While the comment correctly identifies duplicated code, GitHub Actions workflows are typically self-contained files that don't share code. Extracting common logic between workflows would require creating a custom action or shared script, which might be overkill for a single line. The duplication is minimal and the context is clear within each file.
  The comment does identify a real issue of code duplication. Having shared logic could make maintenance easier if this pattern needs to change in the future.
  However, the overhead of creating a shared solution for such a minor duplication would likely introduce more complexity than it's worth. The current approach is more straightforward and maintainable.
  While technically correct, this comment suggests a refactor that would introduce unnecessary complexity for minimal benefit. The comment should be removed.

2. .github/workflows/testing-deployment.yaml:53

• Draft comment:
  This VERSION suffix modification already exists in staging-deployment.yaml. Consider refactoring into a shared workflow step.

• VERSION suffix export (staging-deployment.yaml)

• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
  While the comment identifies a real duplication between files, suggesting workflow refactoring is more of an optional optimization than a required change. The current approach works fine and the duplication is minimal (just one line). Creating a shared workflow step for such a small piece might add unnecessary complexity. Also, these are deployment workflows which sometimes benefit from being explicit rather than DRY.
  The comment does identify a legitimate opportunity for code reuse. Having shared workflow steps could make future changes more maintainable.
  However, the benefit of refactoring this single line is minimal compared to the overhead of creating and maintaining a shared workflow step. The current duplication is acceptable for deployment scripts where explicitness can be valuable.
  Delete this comment as it suggests an optional refactoring that isn't clearly beneficial enough to justify the change.

3. .github/workflows/staging-deployment.yaml:53

• Draft comment:
  Ensure the '-amd64' suffix is intended; verify that the updated VERSION is compatible with subsequent deployment steps.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is asking the PR author to verify the compatibility of a version change, which is against the rules. It does not provide a specific suggestion or point out a clear issue.

4. .github/workflows/testing-deployment.yaml:53

• Draft comment:
  Confirm that appending '-amd64' to VERSION here aligns with testing conventions and that all tools consume the updated tag correctly.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment asks the PR author to confirm their intention and ensure that the change is tested, which violates the rules. It does not provide a specific code suggestion or highlight a potential issue.

5. .github/workflows/staging-deployment.yaml:53

• Draft comment:
  Appending '-amd64' to VERSION here is clear, but please double-check that downstream commands (like docker-compose) expect this modified version. Consider adding a brief comment explaining why the suffix is appended after the build step.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

6. .github/workflows/testing-deployment.yaml:53

• Draft comment:
  Appending '-amd64' to VERSION appears intentional. Please ensure that this suffix aligns with downstream expectations and add a clarifying comment to maintain context.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

7. .github/workflows/testing-deployment.yaml:49

• Draft comment:
  Typographical error: The word "scenerio" in the comment should be corrected to "scenario".
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_BqOQrJ5kRUZDcn6C

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on d9a82e2 in 33 seconds

More details

• Looked at 26 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 5 drafted comments based on config settings.

1. .github/workflows/staging-deployment.yaml:53

• Draft comment:
  Using the first 7 characters of GITHUB_SHA for VERSION ensures predictability, but double-check that all downstream systems expect a commit hash-based version.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

2. .github/workflows/testing-deployment.yaml:53

• Draft comment:
  Ensure that using '${GITHUB_SHA:0:7}-amd64' for VERSION is consistent with version tagging and doesn't conflict with other versioning logic.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

3. .github/workflows/staging-deployment.yaml:53

• Draft comment:
  Changing VERSION to use a 7-character commit hash ensures unique tagging with the amd64 suffix. Verify that both the docker build and docker-compose steps correctly reference this new version value.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

4. .github/workflows/testing-deployment.yaml:53

• Draft comment:
  Using ${GITHUB_SHA:0:7}-amd64 for VERSION promotes consistency and uniqueness. Ensure that downstream processes (docker-compose image tags) correctly use this updated version format.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

5. .github/workflows/testing-deployment.yaml:49

• Draft comment:
  Typo: The word 'scenerio' on line 49 should be corrected to 'scenario' to improve clarity.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_Vt9ZzZrxstZmwQ74

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.