| << Back to previous view |
|
[QB-3388] Gradle Wrapper - Enhancement Request
|
|
| Status: | Closed |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | J. Mash | Assigned To: | Robin Shen |
| Resolution: | Won't Fix | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| File Attachments: |
WrapperDisabled.jpg
WrapperEnabled.jpg
|
| Description |
|
Currently, the Gradle build step allows the user to specify the path to the wrapper executable file, but this becomes quite cumbersome to support in large-scale (hundreds of repos), cross-platform environments.
Ideally, the Gradle build step would first provide a checkbox to disable/enable the usage of the wrapper, then present the user with a textbox allowing them to specify the DIRECTORY where the wrapper lives (which would default to the current workspace, if empty). I'll add mockups for clarity in a moment. |
| Comments |
| Comment by J. Mash [ 02/May/19 05:15 PM ] |
| The idea here is that it would allow QuickBuild to handle any sort of platform abstraction required for successful execution of the wrapper in exactly the same way as it does for a system-provided Gradle executable -- The convenience provided here would be substantial for us, as we have literally hundreds of individual repos for native code that must compile across all three major platforms (Linux, Mac, Windows). |
| Comment by Robin Shen [ 11/Mar/20 07:34 AM ] |
| You can always script the wrapper path to cope with different configurations and platforms. For instance it can be scripted something like ${node.getAttribute("os.name").toLowerCase().contains('windows")?"wrapper.bat":"wrapper.sh"} |