Closed Bug 1673992 Opened 4 years ago Closed 4 years ago

Stop extracting mozharness.zip in the current working directory

Categories

(Firefox Build System :: Task Configuration, task)

Product:
Firefox Build System
Component:
Task Configuration
Type:
task

Tracking

(firefox84 fixed)

Status:
RESOLVED FIXED
Milestone:
84 Branch
Tracking Flags:
Tracking Status
firefox84 --- fixed

People

(Reporter: ahal, Assigned: ahal)

References

Details

Attachments

(1 file)

Bug 1673992 - [taskgraph] Ensure we stop extracting mozharness.zip in the cwd
47 bytes, text/x-phabricator-request
Details | Review

Apparently when extracting a mount, generic-worker will attempt to set file permissions to match the permission level of the user performing the action. If we extract a directory in an existing dir, generic-worker is unable to tell what was part of the zip and what wasn't. So it just changes the file permissions of everything in that dir.

Over in bug 1673069 Pete Moore discovered that the mozharness.zip archive is being extracted into the home directory, resulting in all files there given root privileges. This was apparently fine with older versions of MacOS, but causes issues on BigSur.

We should modify the mozharness.zip to extract into a subdirectory and update paths. Maybe we could modify the zip so that it ends up in the same mozharness dir and paths don't need to be modified.

(In reply to Andrew Halberstadt [:ahal] from comment #0)

This was apparently fine with older versions of MacOS, but causes issues on BigSur.

:bhearsum reminded me that the Catalina workers are running simple engine, so that might be why they are not hitting this issue. However multiuser engine is a lot safer and provides better guarantees of a clean task environment, so we should still prefer multiuser engine and only use simple engine as a last resort.

A side note, this was being extracted into $HOME/workspace rather than $HOME. But I guess that still could have been causing problems as lots of other stuff is there as well.

Summary: Stop extracting mozharness.zip in the $HOME directory → Stop extracting mozharness.zip in the current working directory

Rather than putting a top-level "mozharness" directory in "mozharness.zip",
this puts the root of mozharness at the root of the archive. Then we extract
the archive into a "mozharness" directory. This way the path on disk ends up
being the same, but generic-worker won't attempt to modify the permissions of
files in the cwd.

(In reply to Andrew Halberstadt [:ahal] from comment #2)

A side note, this was being extracted into $HOME/workspace rather than $HOME. But I guess that still could have been causing problems as lots of other stuff is there as well.

I think this problem only happens when extracting to the home directory - are you sure it was extracted to $HOME/workspace? From the task definition it looks to me like the task directory, which is the task user home directory, I believe:

    "mounts": [
      {
        "format": "zip",
        "content": {
          "taskId": "X5XjPiC6TC2tpFef1H11tg",
          "artifact": "public/build/mozharness.zip"
        },
        "directory": "."
      },

Ah, no I'm not sure. When I messed up the attached patch I got:

python2.7: can't open file '/builds/worker/workspace/mozharness/scripts/desktop_unittest.py'

But that was a linux task so was using docker-worker and therefore was not using that mount. So your initial guess is probably still right.

Pushed by ahalberstadt@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e281605f0fd2
[taskgraph] Ensure we stop extracting mozharness.zip in the cwd r=bhearsum
Blocks: 1673067
No longer blocks: 1673069

I think latest iteration on phab should fix the backout, but haven't seen results on try yet. Here's the push:
https://treeherder.mozilla.org/jobs?repo=try&revision=31035bbdc4238800552c15e60ffaf2444aea6788

If those tasks are green in there, feel free to re-land the patch if you want it on central to unblock the DTK work (as I'm PTO tomorrow).

Flags: needinfo?(ahal)

(In reply to Razvan Maries from comment #9)

Andrew, there is another build bustage on your try push: https://treeherder.mozilla.org/jobs?repo=try&revision=31035bbdc4238800552c15e60ffaf2444aea6788&selectedTaskRun=XAbibIrEQg-8cfBufqTRYw.1&searchStr=Android%2C5.0%2CAArch64%2CShippable%2Copt%2CProfile-guided%2Coptimization%2Cbuilds%2Cbuild-android-aarch64-shippable%2Fopt%2CBa

I'm pretty sure this is unrelated to the patch - it's just that artifact builds shouldn't have been chosen. I've pushed https://treeherder.mozilla.org/jobs?repo=try&revision=2f739dc0f991facfd84402afd1a0f0d7c157eda8 that doesn't use artifact builds.

Flags: needinfo?(ahal)

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #10)

(In reply to Razvan Maries from comment #9)

Andrew, there is another build bustage on your try push: https://treeherder.mozilla.org/jobs?repo=try&revision=31035bbdc4238800552c15e60ffaf2444aea6788&selectedTaskRun=XAbibIrEQg-8cfBufqTRYw.1&searchStr=Android%2C5.0%2CAArch64%2CShippable%2Copt%2CProfile-guided%2Coptimization%2Cbuilds%2Cbuild-android-aarch64-shippable%2Fopt%2CBa

I'm pretty sure this is unrelated to the patch - it's just that artifact builds shouldn't have been chosen. I've pushed https://treeherder.mozilla.org/jobs?repo=try&revision=2f739dc0f991facfd84402afd1a0f0d7c157eda8 that doesn't use artifact builds.

Confirmed to be working - I'm going to re-land this.

Pushed by bhearsum@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/581177d88ae0
[taskgraph] Ensure we stop extracting mozharness.zip in the cwd r=bhearsum

https://hg.mozilla.org/mozilla-central/rev/581177d88ae0

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox84: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch

Yay, nice job!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: