[Bug][Github] PR Deploy Time Incorrectly Calculated Using 'inactive' Status Timestamp Instead of 'success' Timestamp

[fazizsoltani]

Search before asking

• [x] I had searched in the issues and found no similar issues.

What happened

Summary The DevLake GitHub plugin currently uses the inactive deployment status timestamp when calculating the deployment time, which is incorrect for determining when the deployment was actually completed. Problem Explanation In GitHub's deployment lifecycle, a previous deployment is often marked inactive when a newer deployment succeeds and supersedes it. This transition to inactive can happen hours or even days after the initial, successful deployment occurred. When DevLake uses the inactive timestamp as the completion time, the resulting metrics (such as PR Deploy Time) become inaccurate. The following GitHub API output illustrates the issue:

gh api "repos/company/repo/deployments/3361340000/statuses" --jq '.[] | {state: .state, created_at: .created_at}'
{
  "created_at": "2025-11-25T11:17:42Z",
  "state": "inactive"
}
{
  "created_at": "2025-11-24T12:51:13Z",
  "state": "success"
}
{
  "created_at": "2025-11-24T12:49:25Z",
  "state": "in_progress"
}
{
  "created_at": "2025-11-24T12:49:19Z",
  "state": "queued"
}
{
  "created_at": "2025-11-24T12:47:57Z",
  "state": "waiting"
}

What do you expect to happen

The actual deployment finished on 2025-11-24T12:51:13Z (the success status time). However, the time being recorded in the DevLake database is the inactive timestamp: 2025-11-25T11:17:42Z.

DevLake should use the timestamp corresponding to the final success status, not the later inactive status, to accurately calculate deployment duration.

How to reproduce

To reproduce the bug, simply create a deployment targeting a specific environment (like production), which will subsequently achieve a success status. Then, after a period of time, add a new commit and trigger a second deployment to that same environment. This second action will automatically cause GitHub to mark the initial, successful deployment as inactive; a documented behavior (see GitHub inactive deployments documentation).

Anything else

No response

Version

v1.0.3-beta8

Are you willing to submit PR?

• [x] Yes I am willing to submit a PR!

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[dosubot[bot]]

Hi @fazizsoltani! I'm Dosu and I’m helping the incubator-devlake team.

You’re right—DevLake currently calculates deployment completion time using the deployment’s overall UpdatedDate, which often reflects the timestamp of the later 'inactive' status, not the actual 'success' status. This logic is in the conversion step (deployment_convertor.go), where FinishedDate and DurationSec are set using githubDeployment.UpdatedDate, regardless of the deployment status.

To fix this, update the conversion logic to select the timestamp of the final 'success' status from the deployment’s status history, rather than the latest update (which could be 'inactive'). You’ll likely need to adjust how statuses are extracted and stored so you can reliably access the correct 'success' timestamp during conversion. The relevant extraction logic is in deployment_extractor.go.

This change will ensure PR Deploy Time metrics reflect the actual deployment completion, not when it was superseded. If you need help navigating the code or want to discuss implementation details, let me know!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[klesh]

Thanks for reporting the issue and taking the initiative to work on it—I’m looking forward to your PR!