Pass arguments to disable sandboxing when enabled#993
Pass arguments to disable sandboxing when enabled#993award999 wants to merge 1 commit intoswiftlang:mainfrom
Conversation
|
Leaving in draft state until we have macOS builders to test this |
adam-fowler
left a comment
There was a problem hiding this comment.
Have you verified that all of these commands will work with all the build arguments.
I'm just wondering if it is safer to have a disable sandbox option which is used in these cases
Ya should have explained in commit message but if you look at: Other than "package" having different subcommands, the options are the same other that build can specify target, product, and enable/disable swift-testing and XCTest. In my mind the user wouldn't put these in build arguments to use for everything but maybe you can think of a case I haven't. Yes the other option is a boolean setting to disable sandboxing but wasn't keen on introducing a new setting for our niche use case, but yes may be safer bet |
To get our tests to run in a sandbox, we need to disable sandboxing because you cannot create a new sandbox when you're already running under a sandbox - Add new `swift.disableSandbox` setting - Disable sandboxing for tasks and commands run by the extension - Disable hardware acceleration since ci.swift.org will run on x64 - Fix failing xcode watcher unit test - Increase some timeouts as build times seem slower on these nodes - Skip any LSP dependent tests for 6.0 or earlier. The LSP will only allow disabling sandboxing in 6.1+ - Disable debugging tests since need shareport permission
These particular commands (or subcommands) take the same build arguments as we pass to "build", "run", and "test" commands. To get our tests to run in a sandbox, we need to disable sandboxing because you cannot create a new sandbox when you're already running under a sandbox