Running tests from windows throws org.apache.commons.io.FileExistsException

Expected behaviour
executeScreenshotTests -Precord and executeScreenshotTests should not throw FileExistsException
Actual behaviour
Running command executeScreenshotTests -Precord is returning
org.apache.commons.io.FileExistsException: Destination '{myProjectPath}\features\{myFeature}\screenshots\debug\screenshots-compose-default\{packageName}testName.png already exists.
Running command executeScreenshotTests is returning
org.apache.commons.io.FileExistsException: Destination '{myProjectPath}\features\{myFeature}\screenshots\debug\screenshots-compose-default\metadata.json_emulator-5554 already exists.
NOTE: I deleted the screenshots directory from my module before running these commands. After these commands run and finish I see the .png, metadata.json-5554 and sometimes the metadata.json files in that directory.
Steps to reproduce
Create a test using compose-ui and run the commands:
gradlew.bat executeScreenshotTests -Precord
gradlew.bat executeScreenshotTests
Version of the library
5.11.0
Also I am using a machine with Windows 10 installed and Android Studio Arctic Fox 2020.3.1 RC1

Linked to https://github.com/Karumi/Shot/issues/140

We're still having there issues on code-with-the-italians/bundel on 5.12.1 unfortunately. Same error as the original report. I'll put a link to the recording of our efforts once the recording is out!
Note: this was mistakenly posted on #140 first.

@pedrovgs I have run the tests on the shot-consumer-flavors and they pass. I noticed the dependencies on that project are very old, and the target Android version is too, so I tried upgrading those. It still passes without issues on the same emulators I have issues with (API 29 and 31). I don't really know what we did in our project that makes it fail; it seems like there's nothing different in the setup, as there is barely anything to set up in the Gradle files...

🤔  🤔  @rock3r, do you mean you've forked the project from your windows PC and got Shot working on shot-consumer-flavors? 🤔  🤔
API 29+ issues I'm sure are related to the scoped storage... but I'm happy to see I'm not crazy and we got Shot working on windows, at least for 1 project xD cc/ @Tylos
Could you please check the other shot-consumer-* sample projects? You can execute record/verify tasks for all of them just to see If we find something failing.
Looking at your Twitch stream I've noticed the line you mentioned about the message We couldn`t pull the screenshots from folder is related to the old UI kit integration and not to the bug we are facing. That yellow warning message is always shown when there are no tests for activities, views, or fragments and you only have tests for composable functions. Sorry, the message can be misleading.
However, there is an interesting point in the video you've already noticed. The Shot Gradle plugin is actually able to pull the screenshots and when it fails, it shows a message ....testName.png already exists. Looks like the images are being pulled multiple times for a reason I don't understand. As you mentioned the shot-consumer-flavor project is working I'm wondering if it can actually be related to the usage of the test orchestrator we don't support or something in your runtime. There is an issue reported here https://github.com/pedrovgs/Shot/issues/78 but I'm not sure if it is related.
@rock3r, now that you've got it running, could you please run some tests for me and check what's going on?

[ ] Record and verify tests in all the shot-consumer-* sample projects using API 28 emulator and let me know if you got Shot passing on all of them or only on some of them.
[ ] Ensure in your project you are not using the AndroidX test orchestrator. Shot is not compatible with this AndroidX feature for now. Maybe it is enabled by default if you've added some updated androidx testing dependencies to your project.
[ ] When you find any of the sample projects failing you can add some log traces and paste the results here.

For the second experiment, you can modify Adb.scala, pullFolder function as follows:
  private def pullFolder(
      folderName: String,
      device: String,
      screenshotsFolder: Folder,
      appId: AppId
  ) = {
    val folderToPull = s"${baseStoragePath}/screenshots/$appId/$folderName/"
    println(s"Pulling screenshots from ${folderToPull}")
    try {
      executeAdbCommandWithResult(s"-s $device pull $folderToPull $screenshotsFolder")
    } catch {
      case t: Throwable =>
        println(s"Exception catch: ${t}")
        println(
          Console.YELLOW + s"Shot ADB warning: We could not pull screenshots from folder: ${folderToPull}"
        )
    }
  }

It will print the folders where Shot is trying to pull the images every time it tries to pull and if it fails it will print the exception found.
Thank you so much @rock3r 😃  I really appreciate the time you are taking to fix this bug!

@mariuszmarzec you are the author of the fix we added as tentative support for windows. Could you please help us with this bug?

🤔 🤔 @rock3r, do you mean you've forked the project from your windows PC and got Shot working on shot-consumer-flavors? 🤔 🤔

Yes! Works fine. Prints some warnings about files not existing when running some ADB commands, but works fine and doesn't fail.
I'll check the other instructions asap and will let you know! :) Thanks a ton for your help 🙌

@pedrovgs I don't remember to have this issue during fixing issue #140, but i will try to have a look this week.

@pedrovgs
Checked today on my windows machine and looks like still this issue is occurring
java.nio.file.FileAlreadyExistsException: F:\AndroidStudioProjects\Shot\shot-consumer\samplelibrary\screenshots\debug\screenshots-default\com.example.samplelibrary.ExampleInstrumentedTest_takeAScreenshotOfAnInflatedLayout_dump.json

Looks like screenshots-default is not removed after/before from some reason. I will try to fix it later.
According to @rock3r 's issue, i cloned Bundel repo and trying to reproduce error as above, but got different one:
at dev.sebastiano.bundel.onboarding.OnboardingAndroidUiTest.intro_page_should_look_nice(OnboardingAndroidUiTest.kt:72)
java.io.IOException: java.io.IOException: No such file or directory
at java.io.UnixFileSystem.createFileExclusively0(Native Method)
at java.io.UnixFileSystem.createFileExclusively(UnixFileSystem.java:317)
at java.io.File.createNewFile(File.java:1008)
at com.karumi.shot.compose.ScreenshotSaver.createFileIfNotExists(ScreenshotSaver.kt:77)
at com.karumi.shot.compose.ScreenshotSaver.saveScreenshotBitmap(ScreenshotSaver.kt:59)
at com.karumi.shot.compose.ScreenshotSaver.saveScreenshot(ScreenshotSaver.kt:21)
at com.karumi.shot.compose.ComposeScreenshot.saveScreenshot(ComposeScreenshot.kt:22)
at com.karumi.shot.ScreenshotTest$DefaultImpls.compareScreenshot(ScreenshotTest.kt:144)
at dev.sebastiano.bundel.onboarding.OnboardingAndroidUiTest.compareScreenshot(OnboardingAndroidUiTest.kt:27)
at com.karumi.shot.ScreenshotTest$DefaultImpls.compareScreenshot(ScreenshotTest.kt:116)
at dev.sebastiano.bundel.onboarding.OnboardingAndroidUiTest.compareScreenshot(OnboardingAndroidUiTest.kt:27)
at com.karumi.shot.ScreenshotTest$DefaultImpls.compareScreenshot$default(ScreenshotTest.kt:114)
at dev.sebastiano.bundel.onboarding.OnboardingAndroidUiTest.intro_page_should_look_nice(OnboardingAndroidUiTest.kt:72)
java.io.IOException: No such file or directory
at java.io.UnixFileSystem.createFileExclusively0(Native Method)
at java.io.UnixFileSystem.createFileExclusively(UnixFileSystem.java:317)
at java.io.File.createNewFile(File.java:1008)

Looks like something different. Maybe it is operating system related. @rock3r Do you use Windows or Linux/MacOS?

@mariuszmarzec I'm on Windows 11

@pedrovgs I created a PR and after those changes @rock3r 's Bundel screenshot testing is working for me.

@mariuszmarzec could you please confirm the emulator you used to test it and also the list of projects and sample projects you've tested? I'd love to release a version with the fix before the end of the year, but I'd like to at least ensure it works for API 28 in different projects.

@pedrovgs I tested all shot-consumer-* project on API-28 and it works as expected. But i have open champagne to early. Looks like issue:
at dev.sebastiano.bundel.onboarding.OnboardingAndroidUiTest.intro_page_should_look_nice(OnboardingAndroidUiTest.kt:72)
java.io.IOException: java.io.IOException: No such file or directory
at java.io.UnixFileSystem.createFileExclusively0(Native Method)
at java.io.UnixFileSystem.createFileExclusively(UnixFileSystem.java:317)

... stills occur on API 29 for compose test.
I think this PR could be merge, but this issue require more investigation rather as separate issue.

@pedrovgs Issue with IOException is probably same as #240
I think we could merge my PR (if everything is ok) and close this issue.

Merged and released, thank you so much @mariuszmarzec 😃 Could you please guys check if 5.12.2 is working as expected, at least on API 28?

I am facing the same issue in our project by using 5.12.2. Mac, emulator API 28. any luck to fix this?

@zoey-juan I discovered that sometimes gradle is locking files created durin shot tasks, and to workaround it you have to run ./gradlew --stop to kill gradle deamon and remove lock on files.
Could you try ./gradlew --stop before runing shot? If any issue still occurs, please share --stacktrace

@mariuszmarzec hi, the FileExistsException error is gone after running ./gradlew --stop, however, the screenshot images didn't not save to the path(screenshots/debug is created but no images inside) even the log says successful. Any other ideas?
This is the log
$ ./gradlew xxxx-compose-app:debugExecuteScreenshotTests -Precord --stacktrace
Type-safe project accessors is an incubating feature.
Configuration on demand is an incubating feature.

> Configure project :xxxx-compose-app
WARNING:: The option setting 'android.enableR8=false' is deprecated.
It will be removed in version 7.0 of the Android Gradle plugin.
You will no longer be able to disable R8
Project property 'kotlin.parallel.tasks.in.project' is deprecated.
By default it depends on Gradle parallel project execution option value.
Shot ADB warning: rm: /storage/emulated/0/Download/screenshots/com.*.xxxx.compose.app.test.uid/screenshots-default/: No such file or directory
Shot ADB warning: rm: /storage/emulated/0/Download/screenshots/com..*.xxxx.compose.app.test.uid/screenshots-compose-default/: No such file or directory

> Task :xxxx-compose-app:connectedDebugAndroidTest
Starting 19 tests on Pixel_3_API_28(AVD) - 9

> Task :xxxx-compose-app:debugDownloadScreenshots
⬇  Pulling screenshots from your connected devices!
Shot ADB warning: We could not pull screenshots from folder: /storage/emulated/0/Download/screenshots/com.*.xxxx.compose.app.test.uid/screenshots-compose-default/
Shot ADB warning: rm: /storage/emulated/0/Download/screenshots/com.*.xxxx.compose.app.test.uid/screenshots-compose-default/: No such file or directorytsAfter

> Task :xxxx-compose-app:debugExecuteScreenshotTests
💾  Saving screenshots.
😃  Screenshots recorded and saved at: /Users/*/Project/*-app-android/xxxx-compose-app/screenshots/debug/
🤓  You can review the execution report here: /Users/*/Project/*-app-android/xxxx-compose-app/build/reports/shot/record/index.html

BUILD SUCCESSFUL in 1m 17s

@zoey-juan Try running it on API 27 or 26. I regularly have problems with any instrumentation tests greater than API 27. Not only for screenshot tests. It could be API 28 handles storage differently so it can't save the screenshots to your device.

I have tried to run on API 27 and debug it. the images are actually stored in /storage/emulated/0/Download/screenshots/com.*.compose.app.test.uid/screenshots-default/ but the log below is trying to pull from screenshots-compose-default/
More details here
$ ./gradlew xxxx-compose-app:debugExecuteScreenshotTests -Precord --stacktrace --debug
[DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ':rrds-compose-app:debugDownloadScreenshots'.
[QUIET] [system.out] ⬇  Pulling screenshots from your connected devices!
[DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ':xxxx-compose-app:debugDownloadScreenshots'.
[QUIET] [system.out] ⬇  Pulling screenshots from your connected devices!
[QUIET] [system.out] Shot ADB warning: We could not pull screenshots from folder: /storage/emulated/0/Download/screenshots/com.*.compose.app.test.uid/screenshots-compose-default/
 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Execute downloadScreenshots for :xxxx-compose-app:debugDownloadScreenshots' completed
 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Executing task ':xxxx-compose-app:debugDownloadScreenshots'' completed
[DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Snapshot outputs after executing task ':xxxx-compose-app:debugDownloadScreenshots'' completed
[DEBUG] [org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter] Removed task artifact state for task ':xxxx-compose-app:debugDownloadScreenshots' from context.
[DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Completing Build operation 'Task :xxxx-compose-app:debugDownloadScreenshots'
[DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Task :xxxx-compose-app:debugDownloadScreenshots' completed
[INFO] [org.gradle.execution.plan.DefaultPlanExecutor] :xxxx-compose-app:debugDownloadScreenshots (Thread[Execution worker for ':' Thread 2,5,main]) completed. Took 0.095 secs.
[DEBUG] [org.gradle.execution.plan.DefaultExecutionPlan] Node :xxxx-compose-app:debugDownloadScreenshots finished executing
[DEBUG] [org.gradle.execution.plan.DefaultExecutionPlan] Node :xxxx-compose-app:debugDownloadScreenshots completed, executed: true
[DEBUG] [org.gradle.execution.plan.Node] Checking if all dependencies are complete for :xxxx-compose-app:debugRemoveScreenshotsAfter
[DEBUG] [org.gradle.execution.plan.Node] All dependencies are complete for :xxxx-compose-app:debugRemoveScreenshotsAfter
[DEBUG] [org.gradle.execution.plan.TaskNode] Checking if all must successors are complete for :xxxx-compose-app:debugRemoveScreenshotsAfter
[DEBUG] [org.gradle.execution.plan.TaskNode] Checking if all finalizing successors are complete for :xxxx-compose-app:debugRemoveScreenshotsAfter
[DEBUG] [org.gradle.execution.plan.TaskNode] All task dependencies are complete for :xxxx-compose-app:debugRemoveScreenshotsAfter
[DEBUG] [org.gradle.execution.plan.Node] Checking if all dependencies are complete for :xxxx-compose-app:debugExecuteScreenshotTests
[DEBUG] [org.gradle.execution.plan.Node] Dependency :xxxx-compose-app:debugRemoveScreenshotsAfter for :xxxx-compose-app:debugExecuteScreenshotTests not yet completed
[DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Execution worker for ':' Thread 2: released lock on :xxxx-compose-app
[DEBUG] [org.gradle.internal.work.DefaultWorkerLeaseService] Worker lease root.1.88 completed (1 worker(s) in use)
2022-01-21T22:37:47.024+0800 [DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Execution worker for ':' Thread 2: released lock on root.1.88
[DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Execution worker for ':' Thread 2: acquired lock on :xxxx-compose-app
 [DEBUG] [org.gradle.internal.work.DefaultWorkerLeaseService] Worker lease root.1.88 started (1 worker(s) in use).
[DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Execution worker for ':' Thread 2: acquired lock on root.1.88
 [INFO] [org.gradle.execution.plan.DefaultPlanExecutor] :xxxx-compose-app:debugRemoveScreenshotsAfter (Thread[Execution worker for ':' Thread 2,5,main]) started.
[DEBUG] [org.gradle.execution.plan.DefaultExecutionPlan] No node could be selected, nodes ready: false
2022-01-21T22:37:47.024+0800 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Task :xxxx-compose-app:debugRemoveScreenshotsAfter' started
[DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Snapshot task inputs for :xxxx-compose-app:debugRemoveScreenshotsAfter' started
[DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Completing Build operation 'Snapshot task inputs for :xxxx-compose-app:debugRemoveScreenshotsAfter'
[DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Executing task ':xxxx-compose-app:debugRemoveScreenshotsAfter'' started
[DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Execute clearScreenshots for :xxxx-compose-app:debugRemoveScreenshotsAfter' started
[QUIET] [system.out] Shot ADB warning: rm: /storage/emulated/0/Download/screenshots/com.*.compose.app.test.uid/screenshots-compose-default/: No such file or directory

@zoey-juan Thanks for logs, yea shot is trying get screenshots from screenshot-compose-default and it failed because it is empty or doesn't exist. Lack of message for screenshot-default means that images are loaded but something went wrong in next stages and final screenshot are not generated.
Are you able build on your local machine shot library with commented out lines:
https://github.com/pedrovgs/Shot/blob/master/core/src/main/scala/com/karumi/shot/Shot.scala#L272-L273
Or you can try locally fetch my branch from this PR https://github.com/pedrovgs/Shot/pull/273 and check it if issue still occurs.

@mariuszmarzec thanks for the suggestion, unfortunately no luck to me. I have tried both suggestions.
May I ask what's the expectation of the output?
Actually we have another two android lib modules with screenshot tests which are working properly. However, I am adding this new application module into our project with screenshot tests, it always not working.
As you can see after running -Precord, the output is as the image below. However, the output from the other two android lib modules, the images go directly into screenshots/debug/*.png instead of creatingscreenshots/debug/screenshots-default/ and screenshots/debug/screenshots-compose-default/.  any idea why the behaviours are different?

hot ADB warning: rm: /storage/emulated/0/Download/screenshots/com.xxx.compose.app.test.uid/screenshots-default/: No such file or directory
Shot ADB warning: rm: /storage/emulated/0/Download/screenshots/com.xxx.compose.app.test.uid/screenshots-compose-default/: No such file or directorytsBefore

> Task :xxx-compose-app:connectedDebugAndroidTest
Starting 20 tests on Pixel_2_API_27(AVD) - 8.1.0

> Task :xxx-compose-app:debugDownloadScreenshots
⬇  Pulling screenshots from your connected devices!
Shot ADB warning: We could not pull screenshots from folder: /storage/emulated/0/Download/screenshots/com.xxx.compose.app.test.uid/screenshots-default/
Shot ADB warning: rm: /storage/emulated/0/Download/screenshots/com.xxx.compose.app.test.uid/screenshots-default/: No such file or directory

> Task :xxx-compose-app:debugExecuteScreenshotTests FAILED
💾  Saving screenshots.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task 'xxx-compose-app:debugExecuteScreenshotTests'.
> 'com.fasterxml.jackson.

@zoey-juan Ok, now it is clear. Something goes wrong during processing metadata.xml file which is intermediate file. screenshots-compose-default and screenshots-default are intermediate directors used to process pulled images from device.
Could you try new released version 5.13.0? In new version there is no xml processing, because facebook screenshot testing used under the hood change metadata to json format. If any issue will occurs again, please share whole stacktrace (usage of --stacktrace flag will make gradle stacktrace printing).

@mariuszmarzec I have tried this PR #273 and I think it's the same as version 5.13.0. the log above was from the change.

@zoey-juan Log is from 5.12.2 probably, because in PR #273 don't use xml parser. Probably during trying code from PR in your test project mavenLocal() repository was not defined before remote repository and 5.12.2 with old code was used. I think you can try 5.13.0 from remote maven repository.

@mariuszmarzec logs and image output by using 3.13.0

```
$ ./gradlew xxxx-compose-app:debugExecuteScreenshotTests -Precord --stacktrace
Type-safe project accessors is an incubating feature.
Configuration on demand is an incubating feature.

Configure project :xxxx-compose-app
WARNING:: The option setting 'android.enableR8=false' is deprecated.
It will be removed in version 7.0 of the Android Gradle plugin.
You will no longer be able to disable R8
Project property 'kotlin.parallel.tasks.in.project' is deprecated.
By default it depends on Gradle parallel project execution option value.
Shot ADB warning: rm: /storage/emulated/0/Download/screenshots/com.x.xxxx.compose.app.test.uid/screenshots-default/: No such file or directory
Shot ADB warning: rm: /storage/emulated/0/Download/screenshots/com.x.xxxx.compose.app.test.uid/screenshots-compose-default/: No such file or directory

Task :xxxx-compose-app:kaptDebugAndroidTestKotlin
warning: Supported source version 'RELEASE_8' from annotation processor 'org.jetbrains.kotlin.kapt3.base.ProcessorWrapper' less than -source '11'

Task :xxxx-compose-app:compileDebugAndroidTestKotlin
w: Flag is not supported by this version of the compiler: -Xallow-jvm-ir-dependencies
w: ATTENTION!
This build uses unsafe internal compiler arguments:

-XXLanguage:+NonParenthesizedAnnotationsOnFunctionalTypes
This mode is not recommended for production use,
as no stability/compatibility guarantees are given on
compiler or generated code. Use it at your own risk!

Task :xxxx-compose-app:connectedDebugAndroidTest
Starting 20 tests on Pixel_2_API_27(AVD) - 8.1.0

Task :xxxx-compose-app:debugDownloadScreenshots
⬇  Pulling screenshots from your connected devices!
Shot ADB warning: We could not pull screenshots from folder: /storage/emulated/0/Download/screenshots/com.x.xxxx.compose.app.test.uid/screenshots-default/
Shot ADB warning: rm: /storage/emulated/0/Download/screenshots/com.x.xxxx.compose.app.test.uid/screenshots-default/: No such file or directory

Task :xxxx-compose-app:debugExecuteScreenshotTests FAILED
💾  Saving screenshots.

FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':xxxx-compose-app:debugExecuteScreenshotTests'.

'com.fasterxml.jackson.databind.ObjectReader com.fasterxml.jackson.databind.ObjectMapper.readerFor(java.lang.Class)'

Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':xxxx-compose-app:debugExecuteScreenshotTests'.
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:187)
at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:268)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:185)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:173)
at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:109)
at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:76)
at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:76)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:74)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:408)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:395)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:388)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:374)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: java.lang.NoSuchMethodError: 'com.fasterxml.jackson.databind.ObjectReader com.fasterxml.jackson.databind.ObjectMapper.readerFor(java.lang.Class)'
at org.json4s.jackson.JsonMethods.parse(JsonMethods.scala:20)
at org.json4s.jackson.JsonMethods.parse$(JsonMethods.scala:19)
at org.json4s.jackson.JsonMethods$.parse(JsonMethods.scala:62)
at com.karumi.shot.json.ScreenshotsComposeSuiteJsonParser$.parseScreenshots(ScreenshotsComposeSuiteJsonParser.scala:16)
at com.karumi.shot.Shot.$anonfun$readComposeScreenshotsMetadata$2(Shot.scala:327)
at scala.collection.TraversableLike.$anonfun$flatMap$1(TraversableLike.scala:293)
at scala.collection.IndexedSeqOptimized.foreach(IndexedSeqOptimized.scala:36)
at scala.collection.IndexedSeqOptimized.foreach$(IndexedSeqOptimized.scala:33)
at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:198)
at scala.collection.TraversableLike.flatMap(TraversableLike.scala:293)
at scala.collection.TraversableLike.flatMap$(TraversableLike.scala:290)
at scala.collection.mutable.ArrayOps$ofRef.flatMap(ArrayOps.scala:198)
at com.karumi.shot.Shot.readComposeScreenshotsMetadata(Shot.scala:320)
at com.karumi.shot.Shot.recordComposeScreenshots(Shot.scala:213)
at com.karumi.shot.Shot.recordScreenshots(Shot.scala:58)
at com.karumi.shot.tasks.ExecuteScreenshotTests.executeScreenshotTests(Tasks.scala:77)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:51)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:29)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$2.run(ExecuteActionsTaskExecuter.java:498)
at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:56)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$run$1(DefaultBuildOperationExecutor.java:71)
at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.runWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:45)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:71)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:483)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:466)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.access$300(ExecuteActionsTaskExecuter.java:105)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.executeWithPreviousOutputFiles(ExecuteActionsTaskExecuter.java:270)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.execute(ExecuteActionsTaskExecuter.java:248)
at org.gradle.internal.execution.steps.ExecuteStep.executeInternal(ExecuteStep.java:83)
at org.gradle.internal.execution.steps.ExecuteStep.access$000(ExecuteStep.java:37)
at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:50)
at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:47)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:76)
at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:76)
at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:47)
at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:37)
at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:68)
at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:38)
at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:50)
at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:36)
at org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:41)
at org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:74)
at org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:55)
at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:51)
at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:29)
at org.gradle.internal.execution.steps.CaptureStateAfterExecutionStep.execute(CaptureStateAfterExecutionStep.java:54)
at org.gradle.internal.execution.steps.CaptureStateAfterExecutionStep.execute(CaptureStateAfterExecutionStep.java:35)
at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:60)
at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:27)
at org.gradle.internal.execution.steps.BuildCacheStep.executeWithoutCache(BuildCacheStep.java:174)
at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:74)
at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:45)
at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:40)
at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:29)
at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:36)
at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:22)
at org.gradle.internal.execution.steps.SkipUpToDateStep.executeBecause(SkipUpToDateStep.java:99)
at org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$0(SkipUpToDateStep.java:92)
at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:52)
at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:36)
at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:84)
at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:41)
at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:37)
at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:27)
at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:91)
at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:49)
at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:78)
at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:49)
at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:105)
at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:50)
at org.gradle.internal.execution.steps.SkipEmptyWorkStep.lambda$execute$2(SkipEmptyWorkStep.java:86)
at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:86)
at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:32)
at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38)
at org.gradle.internal.execution.steps.LoadExecutionStateStep.execute(LoadExecutionStateStep.java:43)
at org.gradle.internal.execution.steps.LoadExecutionStateStep.execute(LoadExecutionStateStep.java:31)
at org.gradle.internal.execution.steps.AssignWorkspaceStep.lambda$execute$0(AssignWorkspaceStep.java:40)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution$2.withWorkspace(ExecuteActionsTaskExecuter.java:283)
at org.gradle.internal.execution.steps.AssignWorkspaceStep.execute(AssignWorkspaceStep.java:40)
at org.gradle.internal.execution.steps.AssignWorkspaceStep.execute(AssignWorkspaceStep.java:30)
at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:37)
at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:27)
at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:49)
at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:35)
at org.gradle.internal.execution.impl.DefaultExecutionEngine$1.execute(DefaultExecutionEngine.java:76)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:184)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:173)
at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:109)
at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:76)
at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:76)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:74)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:408)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:395)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:388)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:374)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)

Get more help at https://help.gradle.org

BUILD FAILED in 44s

@zoey-juan Thanks for effort. Looks like clue of this issue is here:
Caused by: java.lang.NoSuchMethodError: 'com.fasterxml.jackson.databind.ObjectReader com.fasterxml.jackson.databind.ObjectMapper.readerFor(java.lang.Class)'
        at org.json4s.jackson.JsonMethods.parse(JsonMethods.scala:20)

@pedrovgs i'm not experienced in scala, but for me it looks like missing dependency, not sure why is missing. It wasn't never declared in build.gradle file i think and it doesn't break tasks on my machine or CI. Is it connected with scala version? JVM implementation?

Yep, you came to the same error that I mentioned here https://github.com/pedrovgs/Shot/issues/274

@mariuszmarzec looks like there is an issue with the jackson library, like if the dependency is not included as expected or something like that. We could try updating the library we use to decode JSON.

Could this be related to the fact of using JDK 11?

It could be if I've deployed the artifact using java 11 for the final build, but I don't think this is the case. Anyway, our tests are executed using java 11 on linux OS images so it can be something specific to the windows JDK.

Hi,
Caused by: java.lang.NoSuchMethodError: com.fasterxml.jackson.databind.ObjectReader com.fasterxml.jackson.databind.ObjectMapper.readerFor(java.lang.Class)
This issue is fixed for me. I finally found it's bcoz

we add implmentationAndroidTest("...shot-android") cause the dependencies issue.
I replaced fun compareScreenshot(view: View, heightInPx: Int? = null, widthInPx: Int? = null, name: String? = null) with this fun compareScreenshot(bitmap: Bitmap, name: String? = null)
with this two actions, it works now

Releasing a tentative fix for this one right now. Version 5.14.1. Please, if this is still reproducible, feel free to reopen this issue after testing with the new release provided. Thanks!

@pedrovgs As mentionned in the PR, the fix will only fix the Cannot delete directory failing the task and not generating the report.
The next run will still throw the File already exist error

version 5.14.1 still have this issue in my mac machine. and, the problem is, We are having this issue intermittently. now it constantly occurs when i record in one branch and then switched to another branch and run the tests. then this issue occured me... 😢


Convert examples to hcl

Depends on #160
#86

Looks better. Just wondering if these are hcl formatter that can be used to check formatting of these files in presubmit?

Looks better. Just wondering if these are hcl formatter that can be used to check formatting of these files in presubmit?

We may be able to abuse https://terragrunt.gruntwork.io/docs/reference/cli-options/#terragrunt-hclfmt-file for it.

Filed https://github.com/GoogleCloudPlatform/healthcare-data-protection-suite/issues/175


where is the "folia2cpt_corpus.py" file?

I cannot find this file, could you please tell me where it is ?

I'm guessing it is the folia2cpt_input.py script. Can you try that?

Thanks very much. It works for me now.


Field attribute

Implement field attribute which will transform auto property to field on client side (it can be useful if performance is important)
Field attribute can be applied to auto property, class/interface or assembly
[Field]
    public class Class1
    {
        public int Prop1
        {
            get; set;
        }

        public int Prop2 { get; set; } = 2;
    }

    public class Class2
    {
        [Field]
        public int Prop1
        {
            get; set;
        }

        [Field]
        public int Prop2 { get; set; } = 2;
    }

Related to https://github.com/bridgedotnet/Bridge/issues/2234


Fixed problem with api call being out of scope and not updating on su…

…bsequent function calls

Addresses issue #8


Fix SQLServerDatabaseMetadata.getMaxConnections() API query

Currently driver was using sp_configure to fetch 'user connections' configuration which is not correct way to do it. Also with SQL Server 2019, this configuration is moved to 'Advanced Options' hence cannot be run directly as with older SQL Servers.
This PR modifies the query and executes SELECT from sys.configurations which is the recommended way for gathering metadata information.

Codecov Report

Merging #1009 into dev will decrease coverage by 0.02%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##                dev    #1009      +/-   ##
============================================
- Coverage     50.09%   50.06%   -0.03%
+ Complexity     2879     2878       -1
============================================
  Files           120      120
  Lines         27989    27989
  Branches       4677     4677
============================================
- Hits          14020    14012       -8
- Misses        11709    11720      +11
+ Partials       2260     2257       -3

Flag
Coverage Δ
Complexity Δ

#JDBC42
49.57% <100%> (-0.11%)
2835 <0> (-6)

#JDBC43
50.02% <100%> (+0.05%)
2876 <0> (+6)
:arrow_up:

Impacted Files
Coverage Δ
Complexity Δ

...soft/sqlserver/jdbc/SQLServerDatabaseMetaData.java
36.23% <100%> (+0.46%)
68 <0> (+1)
:arrow_up:

...om/microsoft/sqlserver/jdbc/SimpleInputStream.java
52.23% <0%> (-1.5%)
11% <0%> (-1%)

...n/java/com/microsoft/sqlserver/jdbc/Parameter.java
66.33% <0%> (-0.81%)
63% <0%> (ø)

...rc/main/java/com/microsoft/sqlserver/jdbc/DDC.java
46.86% <0%> (-0.44%)
111% <0%> (-1%)

...c/main/java/com/microsoft/sqlserver/jdbc/Util.java
62.5% <0%> (-0.44%)
91% <0%> (-1%)

...oft/sqlserver/jdbc/SQLServerPreparedStatement.java
46.97% <0%> (-0.2%)
189% <0%> (ø)

...rc/main/java/com/microsoft/sqlserver/jdbc/dtv.java
68.18% <0%> (-0.18%)
0% <0%> (ø)

...om/microsoft/sqlserver/jdbc/SQLServerBulkCopy.java
50.39% <0%> (-0.13%)
245% <0%> (-1%)

...in/java/com/microsoft/sqlserver/jdbc/IOBuffer.java
55.45% <0%> (+0.09%)
0% <0%> (ø)
:arrow_down:

... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 84484ed...d83f05e. Read the comment docs.


3.x rely on string keys during validation

This changes the validator to internally always rely on string keys in the given data.
It also adds the option to transform keys and values in passed in data into strings.

Moo, wrong target


Issue in JS Challenge Description of: Use Prototype Properties to Reduce Duplicate Code...

Describe your problem and how to reproduce it:
On the 3rd paragraph in the challenge description frame on the left a prototype is defined as an object. While this may be true for true object oriented languages like C#.net it may not be true in this context and confuse the reader.
The paragraph in question is given below and I added the necessary addition in bold:
"A better way is to use Bird’s prototype. The prototype is an object property that is shared among ALL instances of Bird. "
Add a Link to the page with the problem:
https://learn.freecodecamp.org/javascript-algorithms-and-data-structures/object-oriented-programming/use-prototype-properties-to-reduce-duplicate-code/
Tell us about your browser and operating system:

Browser Name: Google Chrome
Browser Version: Version 76.0.3809.132 (Official Build) (64-bit)
Operating System: Windows 10

If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box):

Nope, the prototype is really an object in this case too so I am closing this :)

This is still confusing as objects also have prototype as a property, explaining this in the challenge description might really help others so I am reopening this.

I think it's fine - what would you like to see here @albert-codestein?


Update Git push policy

what

Update Git push policy

why

Propose a run (shown in the "PR" tab in Spacelift UI) if YAML stack config dependencies affected by the push (before, proposed runs were triggered only when the component's files were changed)

/test all


Remove proposal submission button

Submission closed on June 12, we need to remove the submission button. I suggest replacing with a link to registration.

@acrall - is the registration form ready?

Resolved in PR #64


add: Hash trait for WatchDescriptor

I've made a new PR after breaking the previous one due to a clunky rebase/squash.
I've added the Hash to the WatchDescriptor struct, to allow it to be used for HashMap lookup.

I've implemented the requested changes, thanks!

Can you squash the commits into a single one? That way it's easier to read later. If you're unsure about how to do that, something like git rebase -i origin/master should get you on the way.
Again, if you don't have time or can't be bothered, let me know. I can do it later, no problem. Thanks!

Done!

Hmm, still seeing two commits. Maybe you forgot to push the branch?

It's at 4 commits now, I think I'm doing something wrong! I'm sorry!

No worries! Git can be quite complicated if you're not used to it. That third commit is really weird. It just repeats the change from the third commit, which shouldn't really be possible. Oh well :-)
I'm happy to take care of this for you, but if you want to figure out how to solve this yourself, here's what I would try:

First I would make a second branch to experiment on, so you don't accidentally lose the commits. Like this: git checkout -b backup, where backup can be any valid branch name. That command creates the branch backup and switches over to it.
Then I would get rid of the last two commits, like this: git reset --hard HEAD~2. This resets the branch to your second commit, essentially removing the last two commits from the branch. This can be quite dangerous, that's why we made the backup branch earlier. See [1] for more explanation of HEAD~2.
You should be left with the first two commits now. Run git rebase -i origin/master or git rebase -i HEAD~2. Unless I've made a mistake, both origin/master and HEAD~2 should point to the same commit at this point. This should open a text editor which should show your last two commits.
In the text editor for the interactive rebase, locate the line of your second commit. In that line, replace pick with fixup. Then save and exit the editor. If everything goes right, Git should now merge the second commit into the first one.
You should be left with a single commit. You can push that to your repository now. However, since that push would change an existing commit and delete others, you have to add the -f option to the git push command.

As I said, I'm happy to do it for you. I just figured you might want some pointer on how to solve such problems with Git in the future. Let me know if you want me to do it, or if you have any questions!
[1] HEAD always refers to the last commit of the current branch.  So by resetting to HEAD~2, the last two commits are removed from the branch.

Done!
Thanks for the git help!
I'm quite new to git/github, and still figuring things out. I will take some time out to go through the man pages.
Thank you for your patience.

You're welcome, and thanks again for the pull request!
And regarding Git, it's actually quite elegant under the surface. The only problem is that the elegance is hidden under a thick layer of weirdness :-)


New update crashes on search or when opening a new tab

every time I start a search or open a new tab it freezes and closes its self

I'm going to try to reinstall it if it continues  I will let you know

Can you give more details on what you are trying to search?
Such as which sources you are using, as well as the contents of your main.log and settings.ini file?
Note that both main.log and settings.ini files can be found in C:/Users/%USERNAME%/AppData/Local/Bionus/Grabber in Windows, and in the installation directory on Linux.

here's the main.log

main.log

settings: IDK witch one you needed so I gave all them to you sorry
New Compressed (zipped) Folder.zip

they looked all the same to me
sorry

main.log and settings.ini are missing below you will find screenshots of main.log and settings.ini when I open the settings it blank

I looked up Hearlesssoul and all search engines checked. app just crashes each time


sort programmers in the awards.xsl by their total score

Let's sort them in a reverse order by their total score, in the awards.xsl

@rultor release, tag is 0.0.24

@rultor release, tag is 0.0.24

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.0.24

@yegor256 Done! FYI, the full log is here (took me 10min)


IOGT 16: Chevron Display Fix

@peterp please review

@Mitso is there any way that you can align the arrows in the middle?

@Mitso can I see a screenshot?

@peterp  please review
The footer icon is not yet aligned. Updating that on a different ticket.

Updated:

@peterp please see update

👍


classifcation with gpt

Hi,
May I ask if current code supports using gpt on classification tasks?
Thanks.

Hi,
In our code implementation, we have already supported GPT-2 models.

For other models, such as GPT-neo variants, Llama, OPT, GPT-1, please modify the model loading code in our files.

Thanks, since it is a clarification question, I am closing this now.

Thanks for the quick reply. I run the code with
python run_fsc.py \
    dataset=agnews \
    dataset_seed=0 \
    prompt_length=5 \
    task_lm=roberta-large \
    random_seed=42 \
    report_to_wandb=false

The training takes around 1 day to complete on a single RTX3090, which is much longer than the training time reported in the paper (4 hr). May I ask if this is normal?
I also try to run the code with gpt2 backbone:
python run_fsc.py \
    dataset=agnews \
    dataset_seed=0 \
    prompt_length=5 \
    task_lm=gpt2-xl \
    random_seed=42 \
    report_to_wandb=false

The eval accuracy is only 62.5. Have you experimented with GPT2 on the classification task?


Improve documentation

Add weights to documentation files to control the order of the files.

Continue work in separate PR. Closing.


Review of HIPE 138

HIPE 138 for Rich Schema Contexts has been available for review for one month.
How much longer does the review window stay open before its status may change to accepted?

I think it should be good to merge at this point with no objections @dhh1128 or @TelegramSam can we update this?

Agreed. Please merge, @kdenhartog

@dhh1128 sorry never got back on this. I don't have merge rights on any of the Indy repos. I believe it's you, @TelegramSam and @swcurran who have the rights to merge on this repository.

I have a few initial questions.

It is unclear to me who is creating the schema @id, the client or server? Should the @id be included in the txn set request? If so, the rich schema example is missing an @id key in the data.schema dict.
Is txnId in the set response the same thing as @id?
txnId in set response has the form of L5AD5g65TDQr1PPHHRoiGf1|recipeIngredient|1.0 , with '|' as the delimiter while the current ids have ':' as the delimiter, for example, FC4aWomrA13YyvYC1Mxw7:3:CL:14:some_tag. Is there a good reason to break up continuity and use '|' instead of ':'?


Fix glob

Fixes #708
glob.glob has many possible arguments but the current wrapping solution doesn't cover all them.
This change directly passes all args (positional and kw) as-is to the wrapped function.

You might need to suppress the linting on the line that failed, since the glob signature is different over the different python versions

Thanks for the contribution @Pistahh :+1:


I get error text centos6.5 python2.7.9 scrapy1.1

Traceback (most recent call last):
File "/usr/local/bin/twistd", line 14, in
run()
File "/usr/local/lib/python2.7/site-packages/twisted/scripts/twistd.py", line 29, in run
app.run(runApp, ServerOptions)
File "/usr/local/lib/python2.7/site-packages/twisted/application/app.py", line 617, in run
runApp(config)
File "/usr/local/lib/python2.7/site-packages/twisted/scripts/twistd.py", line 25, in runApp
_SomeApplicationRunner(config).run()
File "/usr/local/lib/python2.7/site-packages/twisted/application/app.py", line 348, in run
self.application = self.createOrGetApplication()
File "/usr/local/lib/python2.7/site-packages/twisted/application/app.py", line 408, in createOrGetApplication
ser = plg.makeService(self.config.subOptions)
File "/soft/portia/slyd/slyd/tap.py", line 107, in makeService
root = create_root(config, settings_module)
File "/soft/portia/slyd/slyd/tap.py", line 48, in create_root
from slyd.projects import create_projects_manager_resource
File "/soft/portia/slyd/slyd/projects.py", line 11, in
from .utils.download import FileSystemProjectArchiver
File "/soft/portia/slyd/slyd/utils/download.py", line 12, in
from slybot.plugins.scrapely_annotations.builder import Annotations
ImportError: No module named builder

Install the builder using
pip install builder

@zhaobingkun You are using an outdated version of slybot. Can you try updating to the latest version


Ensure that Core, Photon & P1 are able to flash voodoospark

oh, thank you! :smile_cat:

They can't all use the same binary though correct?


Automated Package Upgrade

:tada: This PR is included in version 25.3.132 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Wildcard SAN Bug

We believe we have discovered a bug in the certbot-dns-constellix plugin in relation to wildcard SANs.  We consistently see failures in the scenario below.
Issue a certificate for domain.com and *.domain.com using the certbot-dns-constellix plugin as follows: /usr/bin/certbot certonly     --noninteractive --authenticator=dns-constellix --dns-constellix-credentials=/path/to/constellix.ini --dns-constellix-propagation-seconds=60 --domains=domain.com,*.domain.com
When adding the TXT records for DNS validation, both domain.com and *.domain.com require a TXT record for _acme-challenge.domain.com..  LetsEncrypt permits that two records or two values may exist at once for this record, allowing both the domain and its wildcard to be validated at once.  The plugin attempts to add two TXT records of the same name, but Constellix does not permit two TXT records of the same name to exist, preferring instead that multiple values are added to the single record.  As shown below, certbot-dns-constellix works in a fashion incompatible with Constellix.

certbot-dns-constellix orders names alphabetically starting with wildcards
certbot-dns-constellix adds TXT record _acme-challenge.domain.com. for *.domain.com and receives HTTP 200
certbot-dns-constellix attempts to add TXT record _acme-challenge.domain.com. for domain.com and fails with HTTP 400 because the record already exists.
Certificate issuance fails.

To be compatible with Constellix, the certbot-dns-constellix plugin must either modify the existing TXT record with a second value or the Constellix API must accept API add requests for TXT records of the same name.

Thanks for reporting this. We will investigate and work on a fix for the plugin.


Reliably enable code coverage reporting

coverage: 52.547%. remained the same
when pulling fba8dafeeb22e7c862791a6d267e1ca18774c13e on fix/stable/reliably-enable-coverage
into 4fe879dceb4fe8e939225fa24830a08939fdb230 on stable.


Resubmission_group_10_2352383_2352439_2310846_2352381_2353175

Team 10's submission represents two algorithms to solve the 2D Cutting Stock problem: Floor-Ceiling (FC) and Column Generation (CG). These algorithms aim to optimize space utilization, minimize trim loss, and improve runtime performance compared to traditional methods.
Team Members

No.
Full Name
Student ID
Contribution

1
Lê Gia Huy
2352383
Theories + Case studies

2
Nguyễn Tấn Hưng
2352439
Problem Formulation

3
Lê Minh Hào
2310846
Implementing Floor-Ceiling Algorithm

4
Huỳnh Nhật Huy
2352381
Implementing Floor-Ceiling Algorithm

5
Đoàn Vĩ Tiến
2353175
Implementing Column Generation Algorithm

Floor-Ceiling Algorithm (FC)
The Floor-Ceiling Algorithm is a heuristic approach for solving two-dimensional cutting stock problems by packing items into rows (shelves) within a strip. Items are placed either on the "floor" (bottom-up) or the "ceiling" (top-down) based on space optimization, with larger items prioritized to maximize efficiency. Once shelves are created, they are packed into finite bins using the Best-Fit Decreasing Height (BFDH) strategy. This algorithm is effective for medium-sized problems, as it balances computational cost and space utilization. However, its O(n³) time complexity makes it less suitable for very large datasets.
Column Generation Algorithm (CG)
The Column Generation Algorithm is an optimization method that divides the problem into a Master Problem (MP) and a Subproblem. The MP combines existing cutting patterns to meet demand while minimizing material usage, while the Subproblem searches for new patterns with better efficiency. This iterative process alternates between refining patterns and optimizing their use, making it ideal for large-scale problems with complex constraints. While the algorithm achieves excellent material efficiency, its slow convergence near optimal solutions and high computational cost limit its practicality for time-sensitive applications.
Algorithm Performance Metrics

We accidentaly close our previous PR #258 . I create this new PR to correct the older PR that has been closed. We apologize for our mistake and we hope you can accept this new PR, thank you.


Pass config and theme options

I'm trying to setup a gulp task which uses the documentation.yml from the root of the project and a custom theme, but I can't find a place to pass this option through. It seems these options are not exposed in https://github.com/documentationjs/documentation/blob/master/index.js or am I missing something?

Right now it's not possible to pass a configuration file through gulp-documentation: config loading is done in sharedInputOptions, which is part of the documentation bin, and not exposed in the public API. Given that gulp-documentation and there'll be other kinds of access, maybe we should take an approach like .babelrc and parse it by default, even sometimes when it's not what you asked for :)
Or we could just expose a path to loadConfig in the Node API path?


Question about the time complexity of Object DGCNN

From your result in the paper, fps of your model is smaller than other models with nms. And from my understanding, bigger fps means better performance, but you said your model is more efficient. Could you explain it why your model is more efficient with smaller fps?

Sorry this was a mistake. This time complexity was measured without taking NMS into account. We will fix the results soon.


Downloading Prisma engines for windows Error

Bug description
When using npx or installing prisma with npm install im stuck with downloading the Prisma-engine for windows.

Hi @pallemach2
Can you please try again? We have added this missing binary and it should work now.

Hey @pantharshit00,
yea it's working now! Thank you!

don't work :'c
Downloading Prisma engines for windows [                    ] 0%Error: request to https://binaries.prisma.sh/all_commits/b8c35d44de987a9691890b3ddf3e2e7effb9bf20/windows/query-engine.exe.gz.sha256 failed, reason: self signed certificate in certificate chain

reason: self signed certificate in certificate chain

This describes the problem - somewhere in between there is a self signed certificate your computer does not actually trust and hence declines to download the file.

Me too have the same issue...

can anyone help on this.

We still wait for a solution.

Is there an issue for this where we are actually tracking the need for a change in any way?

I think, it is the same issue then here:
https://github.com/prisma/prisma/issues/12457

Downloading Prisma engines for Node-API for windows [                    ] 0%Error: request to https://binaries.prisma.sh/all_commits/0362da9eebca54d94c8ef5edd3b2e90af99ba452/windows/introspection-engine.exe.gz.sha256 failed, reason: unable to get local issuer certificate
when I try to execute> npx prisma init --datasource-provider
I have tried the above suggestion as well but could not resolve it, can any one suggest me on it.

Open a new issue or discussion please. We can not help here in closed issues.


clGetPlatformIDs(-1001) error after a driver update

I re-installed the Nvidia drivers in my laptop and then kinect2_bridge started not working anymore.
I tried to re-install everything from stratch but nothing.
The fact that astonish me is that the example program provided by freenect2 (freeenect2/examples/protonec/bin/Protonec) is perfectly working.
Any suggestion?

Hi,
Protonect is by default not using OpenCL but OpenGL. So if you change it to use OpenCL you will get the same error.
libfreenect2::Freenect2Device *dev = freenect2.openDefaultDevice(new libfreenect2::OpenCLPacketPipeline());

I had the same issue today. I read in another issue that starting sudo ./Protonect (with OpenCL pipeline) once solved it and afterwards it is possible to start it without root. It also solved the problem for me, no clue why.
Other than that you could check if a file /etc/OpenCL/vendors/nvidia.icd exists and if the library mentioned there is found somewhere in /usr/lib.

Thanks very much for the information.
I tried to run the kinect2_bridge node once with sudo and now, magically, everything seem to work.
That is, I tried to run
roscd
cd lib/kinect2_bridge/
sudo ./kinect2_bridge

but, as expected, the node could not connect to the ros master, dying immediately.
Anyway, now lunching roslaunch kinect2_bridge kinec2_bridge.launch works.


multiple agentpool for usergroup

Autoscaler may not scale up evenly across multiple AZ that affects the node distribution, so pods with zone anti-affinity(like etcd) stuck at pending until it finds a node on the right zone.
AKS autoscaler profile does not enable this by default, it can be enabled by --balance-similar-node-group to maintain the node distribution.
This PR make this AKS autoscaler profile change as well as create multiple user agent pool - 1 per AZ.
PR: #586

cc: @weinong @stevekuznetsov @mjlshen

https://github.com/Azure/ARO-HCP/pull/593


Draft does not respect TILLER_NAMESPACE

In early versions of Draft we respected TILLER_NAMESPACE, but it seems like it's been changed to a hardcoded kube-system. That was probably my doing to simplify the CLI overhead. We should re-introduce this as more people are installing tiller in namespaces other than kube-system.

Throwing this into 0.8.0 as an easy fix.


Not able to login

Hello
I just installed the app and I am not able to login to my account.
I am able login on my browser
I reset my password twice still not able to login

Hi, thanks for your report.
Could you provide a bit more information please.
What app version and android version are you using?
Did you upgrade from a previous version or is it a fresh install?
Are you using your email or username to login?
Do you get an error message?
Maybe provide some logs (Settings > Application Logs).

Hi, no need to provide further information, I've already found the possible cause of the problem.
The problem lies in the updated authentication procedure that was introduced with Kitsune version v1.10.5.
The password is transmitted as an encoded string since then (as specified in the official Kitsu documentation here).
However, the API actually expects the password in non-encoded form.
I will be releasing a hotfix soon since this probably affects multiple people.
Thanks for reporting :)

Should be fixed in v1.10.7.
@nvnth Could you please let me know if the login now works with the latest version.

Should be fixed in v1.10.7.
@nvnth Could you please let me know if the login now works with the latest version.

Yes its been fixed
Thanks :)


Pass through errors in get_users method

If we get a timeout or other error, pass through to the Module which
called us so it can handle it.

Coverage remained the same at 71.429% when pulling b57533f559dee642796fdb640c11580331ae67dd on sadir/ch16406/elixir-apps-closex-httpclient-find-all-5 into faded2e23a95933e38471430196fc8bdaf15f717 on master.


Bug:  performance problem in build-bud step of nodejs and nodejs loopback pipeline

Use Kabanero v0.2.0
Tekton pipelines nodejs-build-deploy-pipeline and nodejs-loopback-build-deploy-pipeline run build-bud step take over 40 minutes to complete.
Example of Nodejs Loopback build-bud time:

name: build-bud
terminated:
  containerID: 'cri-o://35d10d642b23d546b147471ee4b2a0591c2a70d7d4c40f62c47e311bf4654049'
  exitCode: 0
  finishedAt: '2019-11-06T15:35:46Z'
  reason: Completed
  startedAt: '2019-11-06T14:48:25Z'

I also see this problem with a single build with nodejs loopback pipeline.  It took about ~ 47 minutes for build-bud step
name: build-bud
terminated:
  containerID: 'cri-o://35d10d642b23d546b147471ee4b2a0591c2a70d7d4c40f62c47e311bf4654049'
  exitCode: 0
  finishedAt: '2019-11-06T15:35:46Z'
  reason: Completed
  startedAt: '2019-11-06T14:48:25Z'

Here is the build-bud log
loopback-buildbud-try2.log.zip

@tseelbach - Please help with assessing this issue and assign it to the appropriate owner.

For nodejs-loopback-build-push-deploy-pipeline, the build step can not be completed, and the build run will fail with error PipelineRun "xxxxx-loopback-webhook-1573776386-2h6ds" failed to finish within "&Duration{Duration:1h0m0s,}"

Looks like there is a fix in the latest buildah to improve performance of the copy step.  Will pull that in and see if there is any improvement in this release.

There is a fix in the latest buildah that reduces the time taken to perform a COPY step within the docker file, however the appsody/appsody-buildah docker image that the pipelines  uses is unable to utilise this later version as other fixes that are required (to prevent mount issues) have not been implemented. This means that we have to continue using buildah v1.9.0 until the fixes for the mount issue has been implemented in the later code and then a newer version of the appsody/appsody-buildah image will be generated for use by the pipelines.

It is under debugging

Gerish and Kyle Christianson would need to help with this this issue.

The node pipelines were failing with the latest buildah.  Looks like there are some new fuse prereqs for it to work.  @aadeshpa could you please look into this when you are back.  Maybe first try to see if we get a performance improvement with the java ones and the new buildah.  Thanks!

is there any profile data available for me to inspect?
what is the baseline we are using to compare? when I was running against an OCP cluster it was a couple of minutes. what changed recently?
is there evidence that file copy is where the time is spent?

Per last discussion with Kyles, these were observed:

The buildah upgrade breaks appsody extract and bunch of other things
fix for that landed in fuse-overlay, not in buildah
fuse-overlay is an os component, not bundled in buildah
so a comprehensive solution is to upgrade buildah in the appsody-buildah image and fuse-overlay into the OS. The first one is easy to do, the second is not - as it involves changing every system that we provision / use.

I would suggest we:

define a baseline where the perf is good (in terms of few minutes)
figure out the step that takes long time (40 minutes) and the change that caused regression and take it from thereon

can you share the pipeline log that has timestamps, to start with?

I tried testing pipelineruns using old appsody buildah image appsody/appsody-buildah:0.5.0-buildah1.9.0 and then with new image appsody/appsody-buildah:0.5.3 and found below results.

One good thing is with the new image appsody-buildah:0.5.3 we are able to run nodejs related pipelines.
However I did not see any performance improvement between the old image and new image. Below are the results.

Pipeline
Buildah image
Time

Java-mp
appsody/appsody-buildah:0.5.3
6 min 20

Java-mp
appsody/appsody-buildah:0.5.0-buildah1.9.0
6 min 22

nodejs-express
appsody/appsody-buildah:0.5.3
16 min

nodejs-express
appsody/appsody-buildah:0.5.0-buildah1.9.0
15 to 17 min

nodejs
appsody/appsody-buildah:0.5.3
12 min

nodejs
appsody/appsody-buildah:0.5.0-buildah1.9.0

thanks @aadeshpa . It would be interesting to see what are the values for loopback, for which this issue was raised originally.

I tested with nodejs-loopback and below is the step in the logs where it stays stuck
[Buildah] Installed:
[Buildah]   diffutils-3.6-5.el8.x86_64               libxkbcommon-0.8.2-1.el8.x86_64
[Buildah]   xkeyboard-config-2.24-3.el8.noarch
[Buildah]
[Buildah] Complete!
[Buildah] 0 files removed
[Buildah] Finished installing dependencies
[Buildah] STEP 14: RUN groupadd --gid 1000 node   && useradd --uid 1000 --gid node --shell /bin/bash --create-home node
[Buildah] STEP 15: RUN mkdir ~/.npm-global
[Buildah] STEP 16: ENV NPM_CONFIG_PREFIX=~/.npm-global
[Buildah] STEP 17: COPY --chown=node:node . /project

then at step
[Buildah] STEP 18: COPY --chown=node:node --from=0 /project/node_modules /project/node_modules

nodejs-loopback
appsody/appsody-buildah:0.5.3
timeout 60   min(pipelinerun failed)

nodejs-loopback
appsody/appsody-buildah:0.5.0-buildah1.9.0

thanks @aadeshpa . I am able to recreate this outside of the pipeline, and have raised a detailed bug report with buildah community.
the problem seems to raise from the fact that we have huge (~200 MB) node_modules folder belonging to the `loopback dependency to be copied to the image.
As we are building the dependency inside the Dockerfile ,  I am not sure why this folder should be there in the first place - looks like it is part of the original template? @raymondfeng

I ran into this issue while building a 1G container.  I used buildah --debug bud . . to verify and saw the .local files where getting put in the container so the buildah process would. run until the filesystem filled.  I put the .local in .dockerignore and was able to buildah bud the image.

@schiwitz - thanks for the info. I tried your workaround, but does not look like it resolving in this case.
[pid 15587]<PHONE_NUMBER>.432003 write(2, "time=\"2019-12-25T06:56:24-08:00\""..., 253time="2019-12-25T06:56:24-08:00" level=debug msg="copyFileWithTar(/root/.appsody/extract/lp/temp/foo/1/0/2/foo.txt, /var/lib/containers/storage/overlay/71ff4c26e61de5d4485815e9c2fad83938899979bbe2e7a5ff80b8fdd79e5469/merged/project/foo/1/0/2/foo.txt)"

...

[pid 15587]<PHONE_NUMBER>.570250 write(2, "time=\"2019-12-25T06:56:24-08:00\""..., 253time="2019-12-25T06:56:24-08:00" level=debug msg="copyFileWithTar(/root/.appsody/extract/lp/temp/foo/1/0/3/foo.txt, /var/lib/containers/storage/overlay/71ff4c26e61de5d4485815e9c2fad83938899979bbe2e7a5ff80b8fdd79e5469/merged/project/foo/1/0/3/foo.txt)"

to process one file, looks like it takes ~150 ms - which seems to be too much, and when that gets multiplied we get into the issue. The loopback project has ~17K nested files / folders!

@gireeshpunathil : I am trying to increase the timeout from 60 min to 120 in the pipelinerun file just for testing, and will let you know what is the exact time it takes to run the nodejs-loopback pipeline successfully.

thanks @aadeshpa . While that number would be of some use, anything that takes more than 5 minutes in this use case is not usable in production, according to me - as we are not talking about GBs, and we are also not talking about network transfer, instead 200 MB from disk-to-memory-to-disk.

@gireeshpunathil : After increasing the timeout, below is the result

nodejs-loopback
appsody/appsody-buildah:0.5.3
85 min with   completion.

nodejs-loopback
appsody/appsody-buildah:0.5.0-buildah1.9.0
in progress

ok, thanks for the news. So, it is indeed moving!

This is held up on the upstream issue with buildah, and the issue is linked above by @gireeshpunathil which is #2047 under buildah repository.

According to Gireesh Punathil: The issue was isolated and raised it with buildah project: https://github.com/containers/buildah/issues/2047

According to Gireesh:  we are good in terms of the debugging, and root cause analysis. The fix is in the master (of buildah). They promised to cut a release early next week, which we can consume.
On the other hand, we may have a challenge in terms of upgrading buildah. I am still making an assessment on that front, and will come up with my observations, before evening

the issue being resolved, verified (by me), a fix devised and a release is planned for next week, through https://quay.io/repository/buildah/stable?tab=tags. that is going to resolve the reported performance issue for loopback pipeline sequences.
but this brings a new challenge. Those who are familiar in this area may recollect the issue reported https://github.com/containers/fuse-overlayfs/issues/116 that inhibited bind mounts with certain types of file systems in the host, and was fixed in fuse-overlayfs v0.7. reference: https://github.com/containers/fuse-overlayfs/issues/116#issuecomment-556310655
I did some study around this, and my current understanding is that the host needs to install / upgrade fuse-overlayfs, not the buildah container (container is already equipped with the right fuse-overlayfs binary, alongside the buildah).
According to https://github.com/containers/fuse-overlayfs/issues/116#issuecomment-556995963 , fuse-overlayfs v0.7 is available in fedora 30/31 , but it is possible that most of the build / test systems are older (the ones that I typically use are RHEL 7.6 / fedora 18)
So this means for this fix to work out of the box, we either need to use latest fedora systems, or / and document this.
I will update here when the release is available, request those who have test systems to test and update how it goes.  @aadeshpa @tam512 @kvijai82 or anyone else!
/cc @marikaj123

@gireeshpunathil : since we were blocked by above issue  to test with your image gireeshpunathil/appsody-buildah:v1 we tried just starting standalone container with your image in RHEL8.0 and followed below steps

Created buildah container with the image
buildah from gireeshpunathil/appsody-buildah:v1

Checked the container

[root@svtcrc-389745-1 lib]# buildah containers
CONTAINER ID  BUILDER  IMAGE ID     IMAGE NAME                       CONTAINER NAME
9fa4b9a96c12     *     1bf9700289a4 registry.access.redhat.com/ubi8/nodejs-10:1-54 nodejs-10-working-container
5d19f7b6eca2     *     05b7c1d1f3e0 docker.io/gireeshpunathil/appsody-buildah:v1 appsody-buildah-working-container

Exec in the container

buildah run -v /var/lib/containers:/var/lib/containers 5d19f7b6eca2 /bin/bash

Initialized nodejs-exp

Appsody init nodejs-loopback(collection 0-5-0)

In same folder where the nodejs exp project was initialized we ran command

appsody build --buildah --buildah-options "--format=docker"
Extracting project from development environment
Pulling docker image docker.io/kabanero/nodejs-express:0.2
Running command: buildah pull docker.io/kabanero/nodejs-express:0.2
60f8beff0a6f1ba2da1820c04f36a93702cea88a33de193cd4059cb9eea7bd8c
[Warning] The stack image does not contain APPSODY_PROJECT_DIR. Using /project
Running command: buildah from --name nodejs-0-5-0-extract -v /nodejs-0-5-0/:/project/user-app docker.io/kabanero/nodejs-express:0.2
Running command: /bin/sh -c x=`buildah mount nodejs-0-5-0-extract`; cp -rf $x//project/* /root/.appsody/extract/nodejs-0-5-0
[Error] buildah mount / copy command failed: exit status 1
Running command: buildah rm nodejs-0-5-0-extract
[Error] buildah mount / copy command failed: exit status 1

So we could not test the appsody build step via your standalone container as well.

@gireeshpunathil - any idea why it works for you on rhel8 and not @aadeshpa? What is different?

@jdmcclur - one or more of:

the tests we ran are different
the systems we used may have different fuse-overlay versions

We are in the process of:

figuring out which RHEL versions match fedora 30/31 where kernel supports new fuse
figuring out earliest known good version of fuse
figuring out the right steps to upgrade fuse
figuring out which test failures map to fuse issue, and which are not.

@marikaj123 : after discussing with @gireeshpunathil he said above nodejs express issue of yum upgrade seems to be separate issue which we saw once in the past for one of the version of appsody/appsody-buildah: . We have created a separate issue for this against the appsody-stack repo
Issue : appsody/stacks#629

This issue seems to be side-effect of the fuse-overlay issue not fixed in the host os where we were testing it which is RHEL8.1 node. Marked it as closed for now. If needed after we know correct environment requirements to test this performance bug issue we can re-open it in collections repo (https://github.com/kabanero-io/collections/issues, not https://github.com/appsody/stacks/issues)and not in the appsody-stack repo where it was created.

@gireeshpunathil : I got another fyre env with single node of ubuntu 18.04.3, where i installed docker and ran your standalone container of gireeshpunathil/appsody-buildah:v1 and followed below steps,
[root@0fa8f723f5b0 nodejs-exp-0-5-0]# exit
exit
root@ub181:~# cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.3 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

Steps Followed

Ran the image gireeshpunathil/appsody-buildah:v1 using docker as a contianer.
Inside the container
2.1 created folder nodjes-exp under /root
2.2 Appsody repo add kab-collections-050 https://github.com/kabanero-io/collections/releases/download/0.5.0/kabanero-index.yaml
2.3 appsody init nodjes-loopback
2.4 Ran appsody build --buildah --buildah-options "--format=docker"

Output : I was able to successfully build the appsody project in 5 to 6 min time. This means first time we could test the fix from @gireeshpunathil in Ubuntu 18.04.3 fyre environment.
cc: @marikaj123 @kvijai82

One more datapoint.  I drove the pipeline against the appsody nodejs loopback stack which is built on top of Ubuntu.  Thought we would avoid the yum upgrade issue in this and get further but unfortunately it also failed pretty early.
[Buildah] Ign:1 http://deb.debian.org/debian stretch InRelease
[Buildah] Get:2 http://security.debian.org/debian-security stretch/updates InRelease [94.3 kB]
[Buildah] Get:3 http://deb.debian.org/debian stretch-updates InRelease [91.0 kB]
[Buildah] Get:4 http://deb.debian.org/debian stretch Release [118 kB]
[Buildah] Get:5 http://deb.debian.org/debian stretch Release.gpg [2365 B]
[Buildah] Get:6 http://deb.debian.org/debian stretch-updates/main amd64 Packages [27.9 kB]
[Buildah] Get:7 http://security.debian.org/debian-security stretch/updates/main amd64 Packages [517 kB]
[Buildah] Get:8 http://deb.debian.org/debian stretch/main amd64 Packages [7086 kB]
[Buildah] Fetched 7937 kB in 8s (936 kB/s)
[Buildah] Reading package lists...
[Buildah] Reading package lists...
[Buildah] Building dependency tree...
[Buildah] Reading state information...
[Buildah] Calculating upgrade...
[Buildah] The following packages will be upgraded:
[Buildah]   libexif-dev libexif12
[Buildah] 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[Buildah] Need to get 663 kB of archives.
[Buildah] After this operation, 1024 B disk space will be freed.
[Buildah] Get:1 http://security.debian.org/debian-security stretch/updates/main amd64 libexif-dev amd64 0.6.21-2+deb9u1 [340 kB]
[Buildah] Get:2 http://security.debian.org/debian-security stretch/updates/main amd64 libexif12 amd64 0.6.21-2+deb9u1 [323 kB]
[Buildah] debconf: delaying package configuration, since apt-utils is not installed
[Buildah] Fetched 663 kB in 0s (927 kB/s)
(Reading database ... 29962 files and directories currently installed.)
[Buildah] Preparing to unpack .../libexif-dev_0.6.21-2+deb9u1_amd64.deb ...
[Buildah] Unpacking libexif-dev (0.6.21-2+deb9u1) over (0.6.21-2+b2) ...
[Buildah] dpkg: error processing archive /var/cache/apt/archives/libexif-dev_0.6.21-2+deb9u1_amd64.deb (--unpack):
[Buildah]  error setting timestamps of '/usr/lib/x86_64-linux-gnu/libexif.so.dpkg-new': Permission denied
[Buildah] Preparing to unpack .../libexif12_0.6.21-2+deb9u1_amd64.deb ...
[Buildah] Unpacking libexif12:amd64 (0.6.21-2+deb9u1) over (0.6.21-2+b2) ...
[Buildah] dpkg: error processing archive /var/cache/apt/archives/libexif12_0.6.21-2+deb9u1_amd64.deb (--unpack):
[Buildah]  error setting timestamps of '/usr/lib/x86_64-linux-gnu/libexif.so.12.dpkg-new': Permission denied
[Buildah] Errors were encountered while processing:
[Buildah]  /var/cache/apt/archives/libexif-dev_0.6.21-2+deb9u1_amd64.deb
[Buildah]  /var/cache/apt/archives/libexif12_0.6.21-2+deb9u1_amd64.deb
[Buildah] E: Sub-process /usr/bin/dpkg returned an error code (1)
[Buildah] subprocess exited with status 100
[Buildah] subprocess exited with status 100
[Buildah] error building at STEP "RUN apt-get update  && apt-get dist-upgrade -y  && apt-get clean  && echo 'Finished installing dependencies'": exit status 100
[Error] exit status 1

Need to conect with RH.

@gireeshpunathil @kvijai82 : attaching the redhat ticket we opened.
Login of Redhat is required to view this ticket.
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_support_cases_-23_case_02579969&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=ybUQK3HdB0XcBntB1pMMhd2balBEJgsoc75thLP5mE0&m=zGusb5XpBzita4kqxPUttmzXYfj5YqpiZfxZdnRKBrs&s=LZtMpA9pYgJg_Y6Ph1hGJ1ULwliuyfzK8-MzYTrJVnE&e=

One of the replies from above ticket:
Message (Associate)
Hunsaker, Jake on Feb 10 2020 at 02:03 PM -05:00
Hello,
My name is Jake and I am a senior member of the containerization team and I am assisting on this case.
With regards to fuse-overlay, it is currently not shipping in RHEL. However, it is scheduled to release with RHEL 7.8 in the RHEL Extras repository. I do not have a shareable ETA for the 7.8 release, however I have added this case to the bug report tracking the release of that package so that we may continue to provide updates on that front.
Regards,
Jake Hunsaker, RHCA Infrastructure II
Principal Container Support Engineer
Red Hat Global Support Services
North America Region

@gireeshpunathil : I tested by following the steps from this issue as you posted : https://github.com/containers/buildah/issues/2047
To measure the time taken to copy
a) multiple folders and files after creating them
[root@svtcrc-389745-1 test_copy_multiple_small_folders]# find ./foo | wc -l
2111
[root@svtcrc-389745-1 test_copy_multiple_small_folders]# du -ms .
4	.
Results
real	3m7.104s
user	1m8.657s
sys	0m32.015s
b) copy tar ball of multiple folder structure from point a)
Result:
real	0m2.151s
user	0m0.466s
sys	0m0.330s
c) copy single 5MB file in txt format
Result:
real	0m2.947s
user	0m0.752s
sys	0m0.420s
d) copy single tar file the above point c) 5MB txt file format
Result:-
real	0m2.239s
user	0m0.474s
sys	0m0.315s
NOTE: As shown in point a result it took  3 min for 2111 folders and files in them to copy, and when I zipped it as tar ball in point b) the copy result took around 2 seconds.

@marikaj123 : We had call with @kvijai82 @gireeshpunathil and<EMAIL_ADDRESS>and Neeraj said they will try to make some copy command changes in the Appsody Stack Docker file to optimize it ,and we will be having a checkpoint with them on Thursday.
Docker file :
https://github.com/appsody/stacks/blob/master/incubator/nodejs-loopback/image/project/Dockerfile

We got some help from<EMAIL_ADDRESS>where he gave us updated appsody nodejs-loopback stack image which has updated COPY commands in dockerfile, which I tried to appsody build in appsody/appsody-buildah:0.5.8-buildah1.9.0 container with the appsody project nodejs-loopback and the result was as below
Result
real	8m0.865s
However when we tried updating the Dockerfile for nodejs-loopback collections stack and build image out of it and then tried to do appsody build in appsody/appsody-buildah:0.5.8-buildah1.9.0 container it gets stuck at below step
[Buildah] Complete!
[Buildah] 0 files removed
[Buildah] STEP 14: RUN mkdir ~/.npm-global
[Buildah] STEP 15: ENV NPM_CONFIG_PREFIX=~/.npm-global
[Buildah] STEP 16: COPY src /project/src
[Buildah] STEP 17: COPY *.* /project/
[Buildah] STEP 18: COPY Dockerfile /project/
[Buildah] STEP 19: COPY user-app /project/user-app/

After the discussion today, @groeges confirmed that nodejs-loopback collection stack is not going to get used from kabanero 0-6-0 so , we are not investigating on nodejs-loopback collection.
We are shifting gears to investigate whether there can me any changes made in nodjes-express and nodejs collection stack Dockerfile to increase their build performance from the help of<EMAIL_ADDRESS>and appsody team.
Today I will try to test modified nodejs-express collection stack image and note the time taken to just run appsody build  of the project from the standalone container appsody/appsody-buildah:0.5.8-buildah1.9.0

Original 0.6.0rc2 nodejs-collection with below appsody config file
bash-5.0# cat .appsody-config.yaml
project-name: nodejs-express-060
stack: docker.io/kabanerobeta/nodejs-express:0.2
With this when i did appsody build --buildah --buildah-options "--format=docker"
``
Result

Built docker image dev.local/nodejs-express-060
Running command: buildah from --name nodejs-express-060-extract docker.io/kabanerobeta/nodejs-express:0.2
Running command: /bin/sh -c x=buildah mount nodejs-express-060-extract; cp -f $x//config/app-deploy.yaml /nodejs-express-060/app-deploy.yaml
Running command: buildah rm nodejs-express-060-extract
Created deployment manifest: /nodejs-express-060/app-deploy.yaml
real	12m23.407s
user	7m37.285s
sys	3m43.267s

2. With my updated COPY commands nodejs-collection 0-6-0rc2 updated image

[root@6088dda3ea3d nodejs-exp-060]# cat .appsody-config.yaml
project-name: nodejs-exp-060
stack: docker.io/aadeshpa/ashish-nj-exp-col-060-build:buildahv2
When i did appsody build --buildah --buildah-options "--format=docker"
Result

[Buildah] Writing manifest to image destination
[Buildah] Storing signatures
[Buildah] afe1d9e09e614990e83cf7716795c24b7030f2caefb2fc111b7800f89dba472e
Built docker image dev.local/nodejs-express-060
Found existing deployment manifest /nodejs-express-060/app-deploy.yaml
Updated existing deployment manifest /nodejs-express-060/app-deploy.yaml
real	3m52.043s
user	1m50.742s
sys	0m37.069s
bash-5.0# ls -la

@steven.groeger @kilnerm: Performance bug in Nodejs stacks
Reference issue : https://github.com/kabanero-io/kabanero-pipelines/issues/121
Summary:
We found out the nodejs , nodejs-express stacks was taking long time in build step, because the Dockerfile for those stacks in Appsody project had single COPY command for whole project and dependency folders. We tried to break it down into logical Sub directory copy commands and @neeraj.laad helped creating the Appsody stack changes which we tried and it gave significant performance by reducing the appsody build  step time from 12 min to 4min .
Then I incorporated that COPY changes in our Kabanero Collections repository nodejs-express stack and created my own image , which I used it in testing the build step and also via kabanero build push pipelinerun  . There was significant reduce in pipelinerun time to almost half the original run time.
Original build-push-pipelinerun  without the changes in the nodejs-express collection stack image
NAME                         SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
test21-manual-pipeline-run   True        Succeeded   18m23s

build-push-pipelinerun  with fixed nodejs-express collection stack image
NAME                         SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
test21-manual-pipeline-run   True        Succeeded   8m26s       0s
[root@bristol-inf sample-helper-files]#

Below are the pull request in Appsody stack from @neeraj.laad
https://github.com/appsody/stacks/pull/680
https://github.com/appsody/stacks/pull/679
Can this change be incorporated in our Collections repository nodes and nodejs-express stack ?
cc: @marikaj @kalathur @gireesh

Final action required to incoporate the fix:-
Can this change be incorporated in our Collections repository nodes and nodejs-express stack ?
cc: @marikaj @kalathur @gireesh

PR for the nodes and nodes-express Dockerfile changes to improve performance:
https://github.com/kabanero-io/collections/pull/286 and https://github.com/kabanero-io/collections/pull/293 and https://github.com/kabanero-io/collections/pull/292

Verified in Kabanero 0.6.0-rc.5.  I could build nodejs and nodejs express pipelines

in less than 10 minutes


fix broken links to QA doc

It looks like someone renamed QA/doc/ to QA/documentation/.  This has broken links in things like issue templates - I experienced it in the RC issue template.  So broken links need to be identified and fixed.
FYI, doc/ is more standard in software projects.

Sorry about that, @pixelzoom. The broken links in the test templates should be fixed now.


Secrets file

There is no secrest.json file in the solution.
So we can no longer build locally...
How do we work around this @rodrigojuarez ?

@Depechie copy and rename the file secrets.json.template, I will update the readme file to include that info.

Can you check in a version that has the right name. That way we don’t need to rename.
You can set git untrack to not include the local one with the secrets in it.
http://codeclimber.net.nz/archive/2016/12/19/ignoring-files-on-git-but-just-for-a-while-with-assume-unchanged/

Can you do a PR with that?

Sure!
But remember before you pull in that PR you still need to do that git command : git update-index --assume-unchanged
Otherwise you will loose the one with the actual secrets in it.
Best to copy it somewhere else on disk and see what happens after the pull.

Sounds good, thanks!


Refactor Kitura-Net HTTPServerDelegate to ServerDelegate

As the title describes, this is a refactoring / renaming of:

The HTTPServerDelegate class protocol in Kitura-net to simply ServerDelegate.
The IncomingMessage class to HTTPIncomingMessage
ServerRequest and ServerResponse into HTTPServerRequest and HTTPServerResponse

There is also a PR against Kitura to support renaming HTTPServerDelegate
All of this is in relation to IBM-Swift/Kitura#565
Description

Pulled HTTPServerDelegate from the HTTPServer class.
Placed it in it's own file, ServerDelegate.swift in Kitura-net.
Replaced all uses of HTTPServerDelegate with ServerDelegate system wide. This affects both the Kitura-Net and Kitura projects.
Renamed IncomingMessage to HTTPIncomingMessage and updated ClientRequest and ServerRequest accordingly.
Renamed ServerResponse to HTTPServerResponse
Renamed ServerRequest to HTTPServerRequest
Created ServerResponse and ServerRequest class protocols so that other modules (Kitura's Router, specifically) can handle response and requests without understanding the underlying protocol (in preperation for FastCGI addition, which will also use the ServerRequest and ServerResponse protocols)
Modified HTTPServer to directly use HTTPServerResponse and HTTPServerRequest

Motivation and Context
ServerDelegate will ultimately be used to provide server protocols other than HTTP and will be used by a forthcoming pull request related to adding a FastCGI server implementation to Kitura. For clarity, this refactor makes it obvious that the ServerDelegate handles more than HTTP and moves it out of the HTTPServer class in the process.
Likewise, IncomingMessage is related exclusively to HTTP operation. Refactoring it to HTTPIncomingMessage makes this clear.
Likewise, ServerRequest and ServerResponse were previously exclusive to HTTP operation. By refactoring them to HTTP-prefixed classes and leaving class protocols in their places, it's now clear that they are related to the HTTP server and other protocols (FastCGI specifically) can inject themselves using the same request and response system.
How Has This Been Tested?
Change is relatively trivial in terms of a refactor. Did a full rebuild of current test projects I'm working on and everything builds and runs as always. There is no real code changes here - just renames/refactors  for the most part. The class protocols mirror the public functions in the original classes so these will sit in for the classes in all calling code without issue (unless something breaks in Swift proper).
Checklist:

[x] I have submitted a CLA form
[ ] If applicable, I have updated the documentation accordingly.
[ ] If applicable, I have added tests to cover my changes.

At this point, I'm done pushing to this PR; this refactors Kitura-net to make it ready for FastCGI to be added. The next PR would be adding the actual FastCGI code.
If there is anything you'd need to get this PR merged, let me know and I can get it done asap.
Thanks!

@simplepanda This fundamentally looks ok. But please update the tests. There is now a test in Kitura-net that uses HTTPServerDelegate

Hi @shmuelk  - I'm just merging back from IBM-Swift/Kitura-net and will push up a commit to update the new tests momentarily.

Ok @shmuelk  - tests updated and it now passes tests on Linux and Mac after refactoring the new parts of the test suite.

Note: Modified the PR description to indicate that I updated the tests.

@simplepanda Thanks. I'll merge this on Sunday. This affects tests in a bunch of other repositories as well. I'll take care of them.

Thanks @shmuelk! - The next changes I have are all clean adds in that they are either new classes to -Net or straight changes to Kitura.git that don't have major dependency problems. Will be much easier to manage.


Pass Play vs Scramble

Is there a way to tell the difference between a QB scramble (a pass play which turns into a rush play) versus a designed QB rush play?

I don't think so. You might consider looking at the human readable description of some of the plays and see if you can develop any heuristics for inferring the type of play from that.

Thanks Andrew. I'll take a look.