feat: implement AI-based deployment job detection in workflows#970
feat: implement AI-based deployment job detection in workflows#970mertilginoglu wants to merge 4 commits intostagingfrom
Conversation
Not up to standards ⛔🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity |
🟢 Coverage 29.76% diff coverage · -0.15% coverage variation
Metric Results Coverage variation ✅ -0.15% coverage variation (-1.00%) Diff coverage ✅ 29.76% diff coverage Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (7917aa6) 10244 4283 41.81% Head commit (853b6e7) 10412 (+168) 4338 (+55) 41.66% (-0.15%) 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 (#970) 168 50 29.76% 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
- Added WorkflowAiService for detecting deployment jobs using AI. - Integrated AI detection into ProjectSettingsComponent with UI updates. - Created backend service and controller for handling detection requests. - Added necessary DTOs and detection logic using OpenAI. - Updated environment configuration for AI integration.
078a61c to
853b6e7
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 853b6e7a0f
ℹ️ 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".
| { | ||
| headers: { | ||
| ...(token ? { Authorization: `Bearer ${token}` } : {}), | ||
| ...(currentRepositoryId ? { 'X-Repository-Id': String(currentRepositoryId) } : {}), |
There was a problem hiding this comment.
Use request repositoryId for X-Repository-Id header
This request builds the URL from the repositoryId argument but sets X-Repository-Id from repositoryService.currentRepositoryId(), so the path and authorization context can diverge. When they differ (for example during route transitions or if this service is reused with an explicit repository id), the backend computes roles from the header and can authorize against the wrong repository or return 403 for a valid maintainer request. Build the header from the same repositoryId argument used in the URL to keep permission checks consistent.
Useful? React with 👍 / 👎.
| const workflowId = this.detectingWorkflowId(); | ||
| if (workflowId == null) { | ||
| return; |
There was a problem hiding this comment.
Scope detection state to each mutation invocation
The mutation callbacks read and clear a single shared detectingWorkflowId, which races when users trigger detection on multiple workflows before earlier calls settle. In that case, one request can overwrite the id of another, causing errors to be recorded under the wrong workflow (or skipped entirely when onSettled from another call sets it to null first). Use per-invocation variables/context (onError(_, vars) and onSettled(_, _, vars)) or a per-workflow pending map instead of shared global state.
Useful? React with 👍 / 👎.
Motivation
Description
Testing Instructions
Prerequisites:
Flow:
Screenshots
Checklist
General
Server
Client