[Question][MLTC] Handling Deployment Hash Mismatch Between GitHub PR Merge and ArgoCD Last Commit

[KelvinVenancio]

Question

Hello everyone, I hope you are doing great today!

I’m back with a new scenario to seek clarification from the more experienced folks.

We use ArgoCD for continuous delivery, and our CI is managed on GitHub. We have a GitHub action that handles the CI process for our apps, with the following flow:

• Merge to master -> deploy on stage
• Merge to stable -> deploy on production

When we merge into stable (let’s focus on production), an action is triggered, which adjusts version definitions in the values files of the repository. Then, a new commit is made with the updated versions during the pipeline. After this, the action proceeds to the final step, updating the stable-release branch with the new content.

Thus, ArgoCD completes the CD process (looking to the stable-release branch), and the process is finalized. No issues with this flow, but for DevLake, it’s a bit tricky because DevLake can’t associate the commit SHA hash of the PR that was merged with the last commit of the stable-release branch, which is where ArgoCD is looking to deploy, sending the deployment commit hash via webhook to DevLake.

From what I’ve read in the docs, DevLake references the commit hash of the merged PR with the commit hash of the deployment. In my current scenario, these are different, affecting the “Median Lead Time for Changes” metric, and the calculation isn’t correct.

In this scenario, is there anything we can do to make this approach work? I thought about considering the successful execution of the action as a deployment, but this would always result in success, as the action process is relatively simple.

I also considered keeping this action execution and considering it as a valid deployment, letting ArgoCD only send a webhook if the deployment fails. However, I might still face the same difficulty in relating a deployment to the merged PR. And I’m not sure if considering a deployment valid and then letting ArgoCD send a failure would be a good idea; I might end up with something duplicated.

The major issue here is that in ArgoCD, the last commit is not the same as the commit of the merged PR, breaking the metric.

Do you guys happen to have any idea here? Thank you.

Screenshots

N/A

Additional context

I tried doing some things in Git, but with any operation the hash changes. What I tried:

• amend the last commit of the stable branch before updating the stable-release branch with the stable content;
• continue letting the action make a new commit, but reverse their order before updating stable-release, but the hash changes too.

[Startrekzky]

Thanks for reporting. @KelvinVenancio

[Startrekzky]

Hi @KelvinVenancio , assuming that you're using the squash mode in GitHub. Is this the problem you're facing?

[KelvinVenancio]

Hi @Startrekzky, it's a little bit different but that example apply well because we also use squash commits. In addition to using squash commit, at the end of everything we merge into another branch and argocd looks at this second branch.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been inactive for 60 days. It will be closed in next 7 days if no further activity occurs.

[github-actions[bot]]

This issue has been closed because it has been inactive for a long time. You can reopen it if you encounter the similar problem in the future.