feat: use configured deploy job for deployment time estimates

[mertilginoglu]

Motivation

Helios currently uses fixed timing assumptions when estimating how long a deployment will stay in pending and in-progress states. That makes the deployment progress view inaccurate for workflows whose actual deploy step starts much later or earlier than the default assumption. This change lets repositories configure the GitHub Actions job that represents the real deployment start so Helios can calculate more accurate build and deploy duration estimates.

Description

• add persistent deployment workflow configuration for GitHub workflows, including a stored deployJobName per workflow
• expose new settings endpoints and generated OpenAPI client methods to read and update deployment workflow configuration
• extend repository settings in the client with a per-workflow "Deployment Job" configuration dialog
• track deployment job timing from GitHub workflow job events and use it to split estimated pre-deployment time from actual deployment time
• store and expose estimated build and deploy durations on deployment/environment DTOs so the client can render more accurate progress timing
• update deployment timing logic in the client to use backend-provided estimates instead of relying only on static defaults
• add migration, service, and test updates needed for the new workflow timing and deployment configuration flow

Testing Instructions

Prerequisites:

• Local Helios setup with server and client running
• A repository connected to Helios that has GitHub Actions workflows and at least one environment using a deployment workflow
• A user with maintainer access for repository settings in Helios
• A GitHub Account without having any additional access-rights (e.g. admin, owner)

Flow:

1. Log in to Helios with a maintainer account
2. Open a repository that has deployment workflows configured for at least one environment
3. Navigate to Settings
4. In the workflow table, click Configure in the new Deployment Job column for a deployment workflow
5. Enter the GitHub Actions job name that represents the actual deployment step and save it
6. Reopen the dialog and verify the configured job name is persisted
7. Trigger a deployment for an environment that uses this workflow
8. After GitHub workflow job data has been synced back to Helios, open the environment or deployment progress view and verify the timing estimate reflects the configured deploy job instead of only the old fixed defaults
9. Repeat the flow with a workflow that has no deployment job configuration and verify Helios still falls back to the default estimate behavior

Checklist

General

• PR description explains the purpose and changes. (f.e. following the 'Conventional Commits')
• Changes have been tested locally.

Server

• Code is performant and follows best practices
• I documented the Java code using JavaDoc style.

[codacy-production]

Not up to standards ⛔

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🔴 Metrics 54 complexity

Metric	Results
Complexity	⚠️ 54 (≤ 20 complexity)

View in Codacy

🟢 Coverage 45.34% diff coverage · +0.14% coverage variation

Metric	Results
Coverage variation	✅ +0.14% coverage variation (-1.00%)
Diff coverage	✅ 45.34% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (0518e03)	8956	3269	36.50%
Head commit (a0573dd)	9112 (+156)	3339 (+70)	36.64% (+0.14%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#939)	161	73	45.34%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{TIP This summary will be updated as you push new changes. Give us feedback}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a0573ddc2a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Enforce repository ownership on deployment-config reads

Validate repositoryId before returning a workflow config. This endpoint currently ignores the path repository and fetches by workflowId alone, so a caller who can access repository A can request /api/settings/{A}/workflows/{workflowId-from-B}/deployment-config and receive repository B’s configuration if they know/guess the workflow ID. This is an authorization boundary bypass and should be fixed by checking the workflow belongs to repositoryId (as done in upsert).

Useful? React with 👍 / 👎.

[meryemefe]

It could be better if we replace this computeEstimate method after findLatestDeployment method because now it has wrong JavaDoc

[meryemefe]

I enabled this flakiness scores update method in staging, which causes merge-conflict now.

[meryemefe]

I tested locally. It works very well. I have only some minor comments. Also, I would like to remind that you need to update the version of flyway while merging conflicts.