Cleanup ActionRun creation #35624
Cleanup ActionRun creation #35624
Conversation
* share more logic
ChristopherHX
added
type/bug
type/refactoring
GiteaBot
added
the
lgtm/need 2
|
This shows how, worse the duplication is at the moment. Preparation for further refactoring. Maybe
At least the surface of doing code path specific inconsistent changes decreases and more tests cover the shared code than the specific code ever did. |
| } | ||
|
|
||
| // FIXME PERF skip this for schedule, dispatch etc. | ||
| CreateCommitStatus(ctx, allJobs...) |
There was a problem hiding this comment.
old code conditionally didn't call this, nested function does the check
| } | ||
|
|
||
| // FIXME PERF do we need this db round trip? | ||
| allJobs, err := db.Find[actions_model.ActionRunJob](ctx, actions_model.FindRunJobOptions{RunID: run.ID}) |
There was a problem hiding this comment.
I wonder why we do not use job objects that insertrun creates? This db read seems like to not bring any advantage for me.
GiteaBot
added
lgtm/need 1
| return fmt.Errorf("LoadAttributes: %w", err) | ||
| } | ||
|
|
||
| vars, err := actions_model.GetVariablesOfRun(ctx, run) |
There was a problem hiding this comment.
Can we use this vars in InsertRun to avoid querying vars again on services/actions/run.go L112?
There was a problem hiding this comment.
Sounds good to me to add vars as parameter to InsertRun
There was a problem hiding this comment.
Passing this as parameter to InsertRun in a5aea1b
I think that caching vars context is good to be part of an interface that is part of the passed context of the workflow run.
Co-authored-by: delvh <dev.lh@web.de> Signed-off-by: ChristopherHX <christopher.homberger@web.de>
GiteaBot
added
lgtm/done
5 participants
Closes #35622