Граф коммитов

4 Коммитов

Автор SHA1 Сообщение Дата
Gregory Szorc b547239226 Bug 1312475 - Add a version parameter to checkouts cache; r=dustin
ff5a4bab0813 (bug 1311791) and 332a08725ed0 (bug 1292071) changed
behavior of the VCS caches. First, the store cache / path was merged
into the checkouts cache. Then the path of the Mercurial shared store
was moved within the cache to always be rooted at the cache root.

Caches are shared across tasks. Tasks can execute on any revision
configured to use a cache. So, when interacting with caches, it is
important to consider how every revision configured to use that
cache will interact with it.

Take this scenario for example.

A worker executes a task where the hg shared store is rooted at
/home/worker/checkouts/src/hg-shared. Then the worker executes a
task where the hg shared store is rooted at
/home/worker/checkouts/hg-store. `hg robustcheckout` will see the
checkout from the first task. But then it sees that the store
it is pointing to is at an unexpected location
(checkouts/src/hg-shared instead of checkouts/hg-store). `hg
robustcheckout` aggressively normalizes state to ensure
consistency. So when it sees this mismatch, it blows away the
checkout and creates one from checkouts/hg-store to replace it.
That's a lot of overhead. And this cycle can repeat itself if
the right combination of revisions run on the worker!

A solution to this problem is to create a clean break from caches
when cache semantics change. In TaskCluster, that means using a
different cache.

This commit introduces a "version" component to the checkouts
cache name. By doing so, we create a clean break from all previous
caches, ensuring all revisions this point forward won't encounter
an hg shared store at an unexpected location. This also paves the
road for easily making additional clean breaks in the future.

MozReview-Commit-ID: JT8yuULKpch

--HG--
extra : rebase_source : 2e5d321e4314ff7543423d3c7837b770b7c8a3a3
2016-10-24 09:58:01 -07:00
Gregory Szorc f67f676a52 Bug 1292071 - Put Mercurial store on same cache as checkout; r=dustin
We were seeing issues with the Mercurial working directory not being
pristine. While I can't reproduce this, I have a hunch it is due to
mixing and matching stores and checkouts in TaskCluster. For example,
if a worker supports running concurrent tasks and 2 tasks arrive at
the same time, the caches for the store and checkout may look like:

  (store0, checkout0)
  (store1, checkout1)

However, the next task may get:

  (store1, checkout0)

This may confuse Mercurial.

This commit eliminates the "hg-shared" cache and places the shared
stores as a sibling directory of the checkout.

MozReview-Commit-ID: 8SzyS6wWf9C

--HG--
extra : rebase_source : 6205f3fe944a6ad2cb833a5a7c0ae5ba136eaea6
2016-10-18 09:46:55 -07:00
Dustin J. Mitchell 123cde8ef1 Bug 1302776: document caches; r=gps
MozReview-Commit-ID: Dy9aXGo5O4u

--HG--
extra : rebase_source : 265f7548bb83db2cc5d8bc5e7bdfbfd81342c7e5
2016-10-20 14:44:26 +00:00
Gregory Szorc 96fa6fe838 Bug 1289643 - Change path for checkouts from "workspace" to "checkouts"; r=dustin
Currently, TaskCluster tasks tend to use the "workspace" directory as
a cache that manages the source checkout *and* additional state.

Historically at Mozilla, we've lumped "source checkout" and "workspace"
(sometimes known as an "objdir") into the same directory. This is
not ideal. Ideally, there is an immutable, read-only source checkout
and all files produced from that source live in a separate directory.

In this commit, the "workspace" directory for the "lint" image has been
renamed to "checkouts" and all tasks using the image have been updated
accordingly. By having "checkout" in the name, we clearly identify this
cache as being relevant to source checkouts, which IMO can serve a
different role from "workspaces." This distinction is important, as the
next commit will prevent the "checkouts" cache from getting optimized
out in certain tasks.

To hammer this point home, documentation on common caches has been
introduced.

MozReview-Commit-ID: BSEc4dM5YCt

--HG--
extra : rebase_source : 5a62939e066d3723736b41e14007112d92346684
2016-07-29 10:44:19 -07:00