Flex unit tests
Hello, we recently transitioned our CI system to run builds offline as opposed to having access to online repositories, and we've run into a problem with our unit tests on a gradlefx build. The build uses the flexSDK dependency as well as sdkAutoInstall, and compileFlex pulls from the filesystem sdk fine, but the tests fail looking for rsl (.swz) files from Adobe online. The swz files are present in the sdk, and the tests pass if I move them into the build directory manually, but I cannot find a way to have the test task look locally for the RSLs as opposed to online.
What are the best practices for performing this? I assume runtime-shared-library-path needs to be overridden, but I was unsuccessful in my attempts. Any help is appreciated.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Yennick Trevels on 07 Jun, 2017 07:23 AM
Hi,
Can you try setting the following property and see what happens:
Probably not something you want to apply in general, but the result of this could steer us in the right direction.
2 Posted by Daniel Rutledge on 07 Jun, 2017 07:41 AM
Hi Yennick, thanks for reaching out. I did already try running the build with
useDebugRSLSwfs = true
and it failed in much the same fashion, as it looks for the necessary SWFs online, but they are stored in the same location in the gradlefx plugin (.gradle/gradlefx/sdks/*hash*/rsls
). Is there a task already available to copy these rsls over to my build directory, or should I go about adding one myself?Support Staff 3 Posted by Yennick Trevels on 07 Jun, 2017 09:14 AM
There's currently no task available which does this already. However, there's the 'copytestresources' task which you might be able to extend.
4 Posted by Daniel Rutledge on 07 Jun, 2017 04:43 PM
Does this commonly have to be done by the implementer when doing Flex Unit tests offline, as these rsls are required by the test runner?
Support Staff 5 Posted by Yennick Trevels on 08 Jun, 2017 06:25 AM
Actually this is something you don't want to burden the implementer with and probably needs fixing inside GradleFx.
6 Posted by Daniel Rutledge on 09 Jun, 2017 05:15 AM
I was able to use runtime-shared-library-path to designate the location of the swz files inside the auto-installed flex sdk of the in the gradlefx plugin. Does the auto-install provide any variables indicating the location of the auto-installed sdk? Currently I have the whole path in there, including the hash to get to the sdk installation.
7 Posted by Daniel Rutledge on 09 Jun, 2017 05:35 AM
Edit: I realize flexHome is supposed to fulfill this purpose, but gradle isn't recognizing it when I use in the compiler options.
Support Staff 8 Posted by Yennick Trevels on 09 Jun, 2017 06:33 AM
probably because you're referencing it too early in Gradle's build lifecycle. By default all definitions in your build.gradle file are evaluated during the evaluation phase, but at this point the SDK hasn't been configured yet by GradleFx.
You can overcome this by setting the compiler options after Gradle's evaluation phase:
9 Posted by Daniel Rutledge on 09 Jun, 2017 08:13 AM
Flash doesn't recognize
${flexHome}
when it's put in the compiler options, but I did have some success with${FLEX_HOME}
--works for the swc, but the path the swz gets mangled and flash can't find it. If I do the full hard-coded path,
the build will succeed, but this isn't an option with the hashed paths to the SDKs.I also tried an alternate approach of adding a copy task that dumps the swz files directly into the directory needed, alleviating need to overwrite the rsl urls, as the fallback just looks for the file right in the build directory. The task below is always claims the source directory is empty, so it never gets run.
10 Posted by Daniel Rutledge on 10 Jun, 2017 04:16 PM
My copy task above was incorrect; I was able to fix it below and copy the rsls into the build directory. The build is now able to find them with the default failover url after it fails to find them online.