Closed Bug 1243381 Opened 4 years ago Closed 4 years ago

Optimize graph scheduling

Categories

(Taskcluster :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: armenzg, Unassigned)

References

Details

I find the execution of the gecko decision task is suboptimal in how long it takes to clone, untar and schedule a graph.

I believe a service could be created that could creates the graphs in a faster manner and create a fake task just to put the logs somewhere.
That service could also be queried to determine scheduling information out of band.

I'm also happy if finding a way where the gecko decision task would be able to have a copy of gecko checked out to begin with, hence, taking short on creating the graph.

For instance, this one is running 10 minutes:
https://tools.taskcluster.net/task-graph-inspector/#TWcsHSXQRASpHjz7q0_GBg/R4ykd1lpQ7Omm5XVBc9tVA/0
Several of the issues here will be addressed by other bugs, first one being moving things that tc-vcs does into the decision task. John has a goal this quarter of prototyping a new mechanism for handling clones and updates. 

I'm not sure we should keep this bug open as it is, because it is so general that it partially covers things happening in several other bugs. 

Considering our backlog, I'm inclined to close this without some more specific work to be done identified.
Fine to dupe against another bug.

This adds up to the end to end for each push.
Once we have decision tasks running on all branches, the gecko-decision workerType will almost always have a fresh cache.  That this runs in docker-worker instead of a dedicated service isn't the issue -- the issue is that hg is slow, and caching is the only way to help that.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.