Chromium Code Reviews
|
|
Chromium Code Reviews|
Created:
3 years, 9 months ago by kthelgason Modified:
3 years, 9 months ago Reviewers:
kjellander_webrtc, vladimirtechman, tommi CC:
webrtc-reviews_webrtc.org Target Ref:
refs/heads/master Project:
webrtc Visibility:
Public. |
DescriptionReland of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #1 id:1 of https://codereview.webrtc.org/2719773002/ )
Reason for revert:
Fixing issues with the framework builder.
Original issue's description:
> Revert of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ )
>
> Reason for revert:
> Looks like this caused the iOS API Framework Builder to fail.
>
> https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20Builder/builds/3487/steps/zip%20archive/logs/stdio
>
> Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip...
> Traceback (most recent call last):
> File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 144, in <module>
> sys.exit(main())
> File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 130, in main
> exit_code = zip_with_subprocess(root, output, entries)
> File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 43, in zip_with_subprocess
> assert os.path.isdir(path), path
> AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/
> step returned non-zero exit code: 1
> @@@STEP_FAILURE@@@
>
> Original issue's description:
> > Do not produce dSYM file for the iOS Frameworks with bitcode
> >
> > Though dSYM files can be generated when building applications or libraries
> > with bitcode. They cannot be used to symbolicate crash reports from
> > applications. Instead, developers need to grab the real dSYM files, which
> > are generated for each specific device type after uploading an iOS / tvOS
> > application to App Store (or to a device using Xcode). Apple clearly warns
> > about it in its documentation:
> >
> > https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION-BITCODE
> >
> > With that in mind, I believe that it would be better to not confuse
> > developers by giving them dSYM files that are not very helpful with
> > the bitcode-enabled framework. Thus, proposing the following modification
> > to the building script, to generate dSYM by default only without
> > the bitcode option. However, if some developers still want to get
> > the dSYM files as a build-process artifact, when enabling bitcode,
> > they can explicitly add --extra-gn-args enable_dsyms=true to the script.
> >
> > Let me know if it lgty.
> >
> > NOTRY=True
> > BUG=None
> >
> > Review-Url: https://codereview.webrtc.org/2705163007
> > Cr-Commit-Position: refs/heads/master@{#16836}
> > Committed: https://chromium.googlesource.com/external/webrtc/+/d74517c52a6cd4172b1f3fdc4e624b6145ff5a0f
>
> TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=None
> NOTRY=True
>
> Review-Url: https://codereview.webrtc.org/2719773002
> Cr-Commit-Position: refs/heads/master@{#16844}
> Committed: https://chromium.googlesource.com/external/webrtc/+/da00077cfac335503b3335d5eac110f2f5bff408
TBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2718983002
Cr-Commit-Position: refs/heads/master@{#16924}
Committed: https://chromium.googlesource.com/external/webrtc/+/28922448012e39f33124bb112e54faecc454dea6
Patch Set 1 #
Created: 3 years, 9 months ago
Messages
Total messages: 15 (4 generated)
Created Reland of Do not produce dSYM file for the iOS Frameworks with bitcode
kjellander@ can you take a look at the build failure and advise Vladimir of what to fix, or alternatively fix it yourself if it's a small fix?
rs lgtm
Can you have PS#1 be the pristine revert of the revert and PS#2 contain the actual fixed version, so I can tell what is the difference?
On 2017/02/27 23:48:52, kjellander_webrtc wrote: > Can you have PS#1 be the pristine revert of the revert and PS#2 contain the > actual fixed version, so I can tell what is the difference? Henrik, I was not sure if your request above was primarily for me, or for your colleagues (or just all three of us). As for the failure that happened with the iOS builder – which I am sorry about – the reason of it is very understandable, after I quickly looked at it today. Last year, the ios_api_framework.py script has been modified to always add the WebRTC.dSYM dir into the zip archive. Here is the related issue: https://codereview.chromium.org/2472473004/ Earlier this year, I have introduced the changes in the Chromium and WebRTC repositories, to support the option for building iOS frameworks (or static libs) with bitcode. After those fixes landed in the master branches, there was a change to the ios_api_framework.py script, to build using bitcode. (I somehow missed that one and was not aware of it, actually, till this situation happened over the weekend.) Here is the review for that specific change: https://chromium-review.googlesource.com/c/433757/ As the logic in ios_api_framework.py was implemented to unconditionally expect the dSYM files after building an iOS framework, it was broken by my changes above – by not providing dSYM files when bitcode is enabled. Considering ios_api_framework.py itself, three solutions are possible, depending on the goals that you have in mind for that zip archive and the dSYM file being added to it: (1) Do not enable the bitcode option inside ios_api_framework.py. And then archive the real dSYM file matching the complied framework. (2) Do build with the bitcode option, but do not expect the dSYM file as a result from the build_ios_libs.py script. As per my description above. (3) Do build with the bitcode option, and explicitly add "enable_dsyms=true" to the "--extra-gn-args" part when calling build_ios_libs.py, to force the generation of the dSYM files, even though they are not useful practically to debug bitcode-enabled frameworks. I hope that helps. Let me know what your thoughts are.
On 2017/02/28 01:53:25, VladimirTechMan wrote: > On 2017/02/27 23:48:52, kjellander_webrtc wrote: > > Can you have PS#1 be the pristine revert of the revert and PS#2 contain the > > actual fixed version, so I can tell what is the difference? > > Henrik, I was not sure if your request above was primarily for me, or for your > colleagues (or just all three of us). As for the failure that happened with the > iOS builder – which I am sorry about – the reason of it is very understandable, > after I quickly looked at it today. PS1 is just the original CL, nothing has been added so far. > Considering ios_api_framework.py itself, three solutions are possible, depending > on the goals that you have in mind for that zip archive and the dSYM file being > added to it: > (1) Do not enable the bitcode option inside ios_api_framework.py. And then > archive the real dSYM file matching the complied framework. > (2) Do build with the bitcode option, but do not expect the dSYM file as a > result from the build_ios_libs.py script. As per my description above. > (3) Do build with the bitcode option, and explicitly add "enable_dsyms=true" to > the "--extra-gn-args" part when calling build_ios_libs.py, to force the > generation of the dSYM files, even though they are not useful practically to > debug bitcode-enabled frameworks. > > I hope that helps. Let me know what your thoughts are. Thanks for the thorough explanation. I'd prefer to go with option 2 here, as I see no point in shipping the dSYM's if they can't be used to symbolicate properly. What do you think Henrik?
On 2017/02/28 09:34:09, kthelgason wrote: > On 2017/02/28 01:53:25, VladimirTechMan wrote: > > On 2017/02/27 23:48:52, kjellander_webrtc wrote: > > > Can you have PS#1 be the pristine revert of the revert and PS#2 contain the > > > actual fixed version, so I can tell what is the difference? > > > > Henrik, I was not sure if your request above was primarily for me, or for your > > colleagues (or just all three of us). As for the failure that happened with > the > > iOS builder – which I am sorry about – the reason of it is very > understandable, > > after I quickly looked at it today. > > PS1 is just the original CL, nothing has been added so far. > > > Considering ios_api_framework.py itself, three solutions are possible, > depending > > on the goals that you have in mind for that zip archive and the dSYM file > being > > added to it: > > (1) Do not enable the bitcode option inside ios_api_framework.py. And then > > archive the real dSYM file matching the complied framework. > > (2) Do build with the bitcode option, but do not expect the dSYM file as a > > result from the build_ios_libs.py script. As per my description above. > > (3) Do build with the bitcode option, and explicitly add "enable_dsyms=true" > to > > the "--extra-gn-args" part when calling build_ios_libs.py, to force the > > generation of the dSYM files, even though they are not useful practically to > > debug bitcode-enabled frameworks. > > > > I hope that helps. Let me know what your thoughts are. > > Thanks for the thorough explanation. I'd prefer to go with option 2 here, as I > see > no point in shipping the dSYM's if they can't be used to symbolicate properly. > > What do you think Henrik? Right, so this was a problem with the buildbot logic expecting that directory to be present. We would have caught this upfront if we would have just run the ios_api_framework bot, which we should always do for changes like this. I'm removing the packaging of the dir in https://chromium-review.googlesource.com/c/448024/ so I'll fire a tryjob here once that's landed.
Description was changed from ========== Reland of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #1 id:1 of https://codereview.webrtc.org/2719773002/ ) Reason for revert: Fixing issues with the framework builder. Original issue's description: > Revert of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ ) > > Reason for revert: > Looks like this caused the iOS API Framework Builder to fail. > > https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20B... > > Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip... > Traceback (most recent call last): > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 144, in <module> > sys.exit(main()) > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 130, in main > exit_code = zip_with_subprocess(root, output, entries) > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 43, in zip_with_subprocess > assert os.path.isdir(path), path > AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/ > step returned non-zero exit code: 1 > @@@STEP_FAILURE@@@ > > Original issue's description: > > Do not produce dSYM file for the iOS Frameworks with bitcode > > > > Though dSYM files can be generated when building applications or libraries > > with bitcode. They cannot be used to symbolicate crash reports from > > applications. Instead, developers need to grab the real dSYM files, which > > are generated for each specific device type after uploading an iOS / tvOS > > application to App Store (or to a device using Xcode). Apple clearly warns > > about it in its documentation: > > > > https://developer.apple.com/library/content/technotes/tn2151/_index.html#//ap... > > > > With that in mind, I believe that it would be better to not confuse > > developers by giving them dSYM files that are not very helpful with > > the bitcode-enabled framework. Thus, proposing the following modification > > to the building script, to generate dSYM by default only without > > the bitcode option. However, if some developers still want to get > > the dSYM files as a build-process artifact, when enabling bitcode, > > they can explicitly add --extra-gn-args enable_dsyms=true to the script. > > > > Let me know if it lgty. > > > > NOTRY=True > > BUG=None > > > > Review-Url: https://codereview.webrtc.org/2705163007 > > Cr-Commit-Position: refs/heads/master@{#16836} > > Committed: https://chromium.googlesource.com/external/webrtc/+/d74517c52a6cd4172b1f3fdc4... > > TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG=None > NOTRY=True > > Review-Url: https://codereview.webrtc.org/2719773002 > Cr-Commit-Position: refs/heads/master@{#16844} > Committed: https://chromium.googlesource.com/external/webrtc/+/da00077cfac335503b3335d5e... TBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=None ========== to ========== Reland of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #1 id:1 of https://codereview.webrtc.org/2719773002/ ) Reason for revert: Fixing issues with the framework builder. Original issue's description: > Revert of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ ) > > Reason for revert: > Looks like this caused the iOS API Framework Builder to fail. > > https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20B... > > Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip... > Traceback (most recent call last): > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 144, in <module> > sys.exit(main()) > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 130, in main > exit_code = zip_with_subprocess(root, output, entries) > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 43, in zip_with_subprocess > assert os.path.isdir(path), path > AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/ > step returned non-zero exit code: 1 > @@@STEP_FAILURE@@@ > > Original issue's description: > > Do not produce dSYM file for the iOS Frameworks with bitcode > > > > Though dSYM files can be generated when building applications or libraries > > with bitcode. They cannot be used to symbolicate crash reports from > > applications. Instead, developers need to grab the real dSYM files, which > > are generated for each specific device type after uploading an iOS / tvOS > > application to App Store (or to a device using Xcode). Apple clearly warns > > about it in its documentation: > > > > https://developer.apple.com/library/content/technotes/tn2151/_index.html#//ap... > > > > With that in mind, I believe that it would be better to not confuse > > developers by giving them dSYM files that are not very helpful with > > the bitcode-enabled framework. Thus, proposing the following modification > > to the building script, to generate dSYM by default only without > > the bitcode option. However, if some developers still want to get > > the dSYM files as a build-process artifact, when enabling bitcode, > > they can explicitly add --extra-gn-args enable_dsyms=true to the script. > > > > Let me know if it lgty. > > > > NOTRY=True > > BUG=None > > > > Review-Url: https://codereview.webrtc.org/2705163007 > > Cr-Commit-Position: refs/heads/master@{#16836} > > Committed: https://chromium.googlesource.com/external/webrtc/+/d74517c52a6cd4172b1f3fdc4... > > TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG=None > NOTRY=True > > Review-Url: https://codereview.webrtc.org/2719773002 > Cr-Commit-Position: refs/heads/master@{#16844} > Committed: https://chromium.googlesource.com/external/webrtc/+/da00077cfac335503b3335d5e... TBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org NOTRY=true BUG=None ==========
On 2017/02/28 22:59:05, kjellander_webrtc wrote: ... > > Right, so this was a problem with the buildbot logic expecting that directory to > be present. We would have caught this upfront if we would have just run the > ios_api_framework bot, which we should always do for changes like this. I totally agree, Henrik. Mea culpa. > I'm removing the packaging of the dir in > https://chromium-review.googlesource.com/c/448024/ so I'll fire a tryjob here > once that's landed. I am wondering why would not we make that part of the building bot a little more universal and less fragile, on any possible future changes related to the dSYM directory? Something like: dsym_output_dir = output_dir.join('WebRTC.dSYM') if os.path.isdir(dsym_output_dir): pkg.add_directory(dsym_output_dir) (well, depending on what API to check the presence of file / directory is available inside that script).
The CQ bit was checked by kjellander@webrtc.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...
CQ is committing da patch.
Bot data: {"patchset_id": 1, "attempt_start_ts": 1488324632976840, "parent_rev":
"93a26f6bb8015f0f3d6d5a1faa3287b086a7f94f", "commit_rev":
"28922448012e39f33124bb112e54faecc454dea6"}
Message was sent while issue was closed.
Description was changed from ========== Reland of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #1 id:1 of https://codereview.webrtc.org/2719773002/ ) Reason for revert: Fixing issues with the framework builder. Original issue's description: > Revert of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ ) > > Reason for revert: > Looks like this caused the iOS API Framework Builder to fail. > > https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20B... > > Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip... > Traceback (most recent call last): > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 144, in <module> > sys.exit(main()) > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 130, in main > exit_code = zip_with_subprocess(root, output, entries) > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 43, in zip_with_subprocess > assert os.path.isdir(path), path > AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/ > step returned non-zero exit code: 1 > @@@STEP_FAILURE@@@ > > Original issue's description: > > Do not produce dSYM file for the iOS Frameworks with bitcode > > > > Though dSYM files can be generated when building applications or libraries > > with bitcode. They cannot be used to symbolicate crash reports from > > applications. Instead, developers need to grab the real dSYM files, which > > are generated for each specific device type after uploading an iOS / tvOS > > application to App Store (or to a device using Xcode). Apple clearly warns > > about it in its documentation: > > > > https://developer.apple.com/library/content/technotes/tn2151/_index.html#//ap... > > > > With that in mind, I believe that it would be better to not confuse > > developers by giving them dSYM files that are not very helpful with > > the bitcode-enabled framework. Thus, proposing the following modification > > to the building script, to generate dSYM by default only without > > the bitcode option. However, if some developers still want to get > > the dSYM files as a build-process artifact, when enabling bitcode, > > they can explicitly add --extra-gn-args enable_dsyms=true to the script. > > > > Let me know if it lgty. > > > > NOTRY=True > > BUG=None > > > > Review-Url: https://codereview.webrtc.org/2705163007 > > Cr-Commit-Position: refs/heads/master@{#16836} > > Committed: https://chromium.googlesource.com/external/webrtc/+/d74517c52a6cd4172b1f3fdc4... > > TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG=None > NOTRY=True > > Review-Url: https://codereview.webrtc.org/2719773002 > Cr-Commit-Position: refs/heads/master@{#16844} > Committed: https://chromium.googlesource.com/external/webrtc/+/da00077cfac335503b3335d5e... TBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org NOTRY=true BUG=None ========== to ========== Reland of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #1 id:1 of https://codereview.webrtc.org/2719773002/ ) Reason for revert: Fixing issues with the framework builder. Original issue's description: > Revert of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ ) > > Reason for revert: > Looks like this caused the iOS API Framework Builder to fail. > > https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20B... > > Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip... > Traceback (most recent call last): > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 144, in <module> > sys.exit(main()) > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 130, in main > exit_code = zip_with_subprocess(root, output, entries) > File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 43, in zip_with_subprocess > assert os.path.isdir(path), path > AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/ > step returned non-zero exit code: 1 > @@@STEP_FAILURE@@@ > > Original issue's description: > > Do not produce dSYM file for the iOS Frameworks with bitcode > > > > Though dSYM files can be generated when building applications or libraries > > with bitcode. They cannot be used to symbolicate crash reports from > > applications. Instead, developers need to grab the real dSYM files, which > > are generated for each specific device type after uploading an iOS / tvOS > > application to App Store (or to a device using Xcode). Apple clearly warns > > about it in its documentation: > > > > https://developer.apple.com/library/content/technotes/tn2151/_index.html#//ap... > > > > With that in mind, I believe that it would be better to not confuse > > developers by giving them dSYM files that are not very helpful with > > the bitcode-enabled framework. Thus, proposing the following modification > > to the building script, to generate dSYM by default only without > > the bitcode option. However, if some developers still want to get > > the dSYM files as a build-process artifact, when enabling bitcode, > > they can explicitly add --extra-gn-args enable_dsyms=true to the script. > > > > Let me know if it lgty. > > > > NOTRY=True > > BUG=None > > > > Review-Url: https://codereview.webrtc.org/2705163007 > > Cr-Commit-Position: refs/heads/master@{#16836} > > Committed: https://chromium.googlesource.com/external/webrtc/+/d74517c52a6cd4172b1f3fdc4... > > TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG=None > NOTRY=True > > Review-Url: https://codereview.webrtc.org/2719773002 > Cr-Commit-Position: refs/heads/master@{#16844} > Committed: https://chromium.googlesource.com/external/webrtc/+/da00077cfac335503b3335d5e... TBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org NOTRY=true BUG=None Review-Url: https://codereview.webrtc.org/2718983002 Cr-Commit-Position: refs/heads/master@{#16924} Committed: https://chromium.googlesource.com/external/webrtc/+/28922448012e39f33124bb112... ==========
Message was sent while issue was closed.
Committed patchset #1 (id:1) as https://chromium.googlesource.com/external/webrtc/+/28922448012e39f33124bb112...
Message was sent while issue was closed.
On 2017/02/28 23:22:00, VladimirTechMan wrote: > On 2017/02/28 22:59:05, kjellander_webrtc wrote: > ... > > > > Right, so this was a problem with the buildbot logic expecting that directory > to > > be present. We would have caught this upfront if we would have just run the > > ios_api_framework bot, which we should always do for changes like this. > > I totally agree, Henrik. Mea culpa. > > > I'm removing the packaging of the dir in > > https://chromium-review.googlesource.com/c/448024/ so I'll fire a tryjob here > > once that's landed. > > I am wondering why would not we make that part of the building bot a little more > universal and less fragile, on any possible future changes related to the dSYM > directory? Something like: > > dsym_output_dir = output_dir.join('WebRTC.dSYM') > if os.path.isdir(dsym_output_dir): > pkg.add_directory(dsym_output_dir) > > (well, depending on what API to check the presence of file / directory is > available inside that script). You're right. I think it would be even better if we just zipped everything in a single directory, so if we could change the script to that instead we wouldn't need to have this fragile add-each-item-individually logic on the buildbot side. I guess it was just that we wanted the zip layout to be of a specific kind (i.e. no sub-dir) and that not all that was built actually was going to be included. Best would be if this script handled the packaging instead of the buildbot step. Then it could just upload the file directly. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
