[webkitpy] Symlink daemons into simulator runtime root

• Component: Tools / Tests
• Status: RESOLVED WONTFIX

[Jonathan Bedard]

WebKit daemons live inside the WebKit framework. However, we can't start these daemons during testing because they live outside the runtime root of the simulator. If we symlink our daemons into the simulator runtime root, we can safely test them.

[Radar WebKit Bug Importer]

<rdar://problem/85362551>

[Jonathan Bedard]

Created attachment 444125 [details]
Patch

[Jonathan Bedard]

Pull-request: https://github.com/WebKit/WebKit/pull/38

[Brady Eidson]

Comment on attachment 444125 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=444125&action=review

> Tools/Scripts/webkitpy/api_tests/manager.py:156
> +            # Daemons can't be called from outside the runtime root

I would phrase a bit differently, like:
"A Daemons executable path must be located within the runtime root"

[Alexey Proskuryakov]

Comment on attachment 444125 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=444125&action=review

> Tools/ChangeLog:3
> +        [webkitpy] Symlink daemons into simulator runtime root

Does this modify what's inside /Applications/Xcode.app? If so, this seems very undesirable.

[Jonathan Bedard]

(In reply to Alexey Proskuryakov from comment #5)
> Comment on attachment 444125 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=444125&action=review
> 
> > Tools/ChangeLog:3
> > +        [webkitpy] Symlink daemons into simulator runtime root
> 
> Does this modify what's inside /Applications/Xcode.app? If so, this seems
> very undesirable.

Yes, not sure there is another way to do this, though. Simulators can't interact with daemons outside of their runtime root. We're sticking the binaries in a place that shouldn't effect anything.

[Brady Eidson]

(In reply to Jonathan Bedard from comment #6)
> (In reply to Alexey Proskuryakov from comment #5)
> > Comment on attachment 444125 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=444125&action=review
> > 
> > > Tools/ChangeLog:3
> > > +        [webkitpy] Symlink daemons into simulator runtime root
> > 
> > Does this modify what's inside /Applications/Xcode.app? If so, this seems
> > very undesirable.
> 
> Yes, not sure there is another way to do this, though. Simulators can't
> interact with daemons outside of their runtime root. We're sticking the
> binaries in a place that shouldn't effect anything.

Right.

We chose a symlink location that has zero chance of conflicting with any other built-in file that might end up in a future runtime root, and a near-zero chance of affecting anything else with the runtime.

To test our daemons (which is a quite desirable thing to do) we have no other identified options.

[Jonathan Bedard]

Landed https://commits.webkit.org/244216@main (r285772)!

If we come up with a better technique in the coming weeks, happy to remove this. I think it's important to unblock testing for now, though.

[Brady Eidson]

(In reply to Jonathan Bedard from comment #8)
> Landed https://commits.webkit.org/244216@main (r285772)!
> 
> If we come up with a better technique in the coming weeks, happy to remove
> this. I think it's important to unblock testing for now, though.

This patch worked for you locally, for me locally, and for EWS here when you put the patch in the queue.

But with my patch over in https://bugs.webkit.org/show_bug.cgi?id=232982 it fails to do the link:
https://ews-build.webkit.org/#/builders/9/builds/58765

[Alexey Proskuryakov]

I think that this is strictly unacceptable, whether there is another solution or not. I will be reverting this change.

[Jonathan Bedard]

Reverted r285772 for reason:

Ownership issues in some XCode installs

Committed r285779 (244223@main): <https://commits.webkit.org/244223@main>

[Jonathan Bedard]

Reverted the change because it didn't unblock Brady anyways and I think Brady's patch meant that this change was breaking some EWS queues.

I do think that symlinking is still the right approach, but let's figure out our options next week.

[Jonathan Bedard]

Created attachment 444276 [details]
Patch

[Jonathan Bedard]

Brady found another way to solve this problem, closing this bug.