KelvinVenancio opened a new issue, #7463:
URL: https://github.com/apache/incubator-devlake/issues/7463
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
## 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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
