You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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:
The text was updated successfully, but these errors were encountered: