1717691 - Caching error when using `--full`

Status: RESOLVED FIXED

(Developer Infrastructure :: Try, defect)

Description

[Andrew Halberstadt [:ahal]]

Looks like there's a bug in the mach try cache. This could be a regression from bug 1714178.

STR:

$ touch taskcluster/mach_commands.py  # invalidates cache
$ ./mach try fuzzy --full --no-push -q "'shippable 'mochitest-browser-chrome"
# lots of tasks displayed
$ ./mach try fuzzy --full --no-push -q "'shippable 'mochitest-browser-chrome"
# no tasks are displayed

Workaround:
Touch any file under the taskcluster directory to invalidate the cache.

Comment 1

[Andrew Halberstadt [:ahal]]

Attachment: Bug 1717691 - [tryselect] Ensure we re-compute the cache key for target_task_set after '--full', r?mhentges!

When a user runs 'mach try --full', we continue computing the target task set
and cache it anyway (since we were already almost there and starting over in
the event they re-run without '--full' is very expensive.

However, when implementing the 'cache_key' function in bug 1714178, I forgot to
recompute the key in this case, causing the contents of 'target_task_set' to
overwrite the 'full_task_set' cache.

This also includes a minor improvement to re-use the 'full_task_set' cache
regardless of 'disable_target_task_filter', as that flag has zero bearing on
the full task graph. This should result in fewer cache misses when using
--full.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9209b676c9ea
[tryselect] Ensure we re-compute the cache key for target_task_set after '--full', r=mhentges

Comment 3

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/9209b676c9ea

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1714178