Android - .aar Artifacts not deployed with latest release (1.40.0)

Describe the bug
I've been using for a long time a GitLab CI/CD script to upload artifacts to Artifactory. Suddenly, the artifacts were not deployed, with no errors or warning. I came here to check and I notice you've created a new release 3days ago. And the last time a deploy succeed was indeed 3days ago.
To Reproduce
Here's part of the GitLab YAML script I'm using:
.install_gradle: &install_gradle |
  curl -L https://services.gradle.org/distributions/gradle-$GRADLE_VERSION-all.zip -o gradle.zip
  unzip -q gradle.zip
  export GRADLE_HOME=$(pwd)/gradle-$GRADLE_VERSION
  export PATH=${GRADLE_HOME}/bin:${PATH}
  echo $GRADLE_HOME
  echo $PATH
  gradle -v

.connect_artifactory: &connect_artifactory |
  curl -fL https://getcli.jfrog.io | sh -s v1.39.7
  ./jfrog rt config --url=$ARTIFACTORY_URL --user=$ARTIFACTORY_USER --password=$ARTIFACTORY_PASS
  ./jfrog rt c show

.upload_artifact: &upload_artifact |
  ./jfrog rt gradle-config --use-wrapper=true --repo-resolve=$GRADLE_REPO_KEY --server-id-resolve=Default-Server --repo-deploy=$GRADLE_REPO_KEY --server-id-deploy=Default-Server
  ./jfrog rt gradle clean artifactoryPublish -b build.gradle --build-name=$ARTIFACT_NAME --build-number=$CI_JOB_ID

# JOB:
publish:
  stage: deploy
  cache: {}
  script:
    # Download and Install Gradle
    - *install_gradle
    # Connect to JFrog Artifactory
    - *connect_artifactory
    # Replace the repository name in the configuration.yml to the correct one.
    - sed -i 's,GRADLE_REPO_KEY,'"$GRADLE_REPO_KEY"',g' configuration.yaml
    # Upload artifact to JFrog Artifactory
    - *upload_artifact

Expected behavior
The artifact should be uploaded/deplyed to Artifactory
Screenshots
Instead of screenshot I can provide logs from GitLab CI/CD Job. One think I've notice is that when the deployment was working the logs were much bigger, it seems like some gradle task were not executing
Log when the deployment work:
------------------------------------------------------------
Gradle 5.6.4
------------------------------------------------------------

Build time:   2019-11-01 20:42:00 UTC
Revision:     dd870424f9bd8e195d614dc14bb140f43c22da98

Kotlin:       1.3.41
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.14 compiled on March 12 2019
JVM:          11.0.8 (Ubuntu 11.0.8+10-post-Ubuntu-0ubuntu120.04)
OS:           Linux 4.4.0-190-generic amd64

$ curl -fL https://getcli.jfrog.io | sh # collapsed multi-line command
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   178  100   178    0     0    528      0 --:--:-- --:--:-- --:--:--   528

100  1344  100  1344    0     0   3490      0 --:--:-- --:--:-- --:--:--  3490
Downloading the latest version of JFrog CLI...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

100 19.0M  100 19.0M    0     0  24.8M      0 --:--:-- --:--:-- --:--:-- 24.8M
[Info] Encrypting password...
Server ID: Default-Server
Url: <myArtifactoryURL>
User: <myArtifactoryUser>
Password: <myPass>
Default:  true

$ sed -i 's,GRADLE_REPO_KEY,'"$GRADLE_REPO_KEY"',g' configuration.yaml
$ ./jfrog rt gradle-config --use-wrapper=true --repo-resolve=$GRADLE_REPO_KEY --server-id-resolve=Default-Server --repo-deploy=$GRADLE_REPO_KEY --server-id-deploy=Default-Server # collapsed multi-line command
[Info] gradle build config successfully created.
[Info] Downloading bintray/jcenter/org/jfrog/buildinfo/build-info-extractor-gradle/4.15.2/build-info-extractor-gradle-4.15.2-uber.jar
[Info] Downloaded 1 artifact.
[Info] Running gradle command: ./gradlew --init-script /root/.jfrog/dependencies/gradle/4.15.2/gradle.init clean artifactoryPublish -b build.gradle
Downloading https://services.gradle.org/distributions/gradle-5.6.4-all.zip
.....................................................................................................................................
Unzipping /builds/sebasira/android-module-boilerplate/.gradle/wrapper/dists/gradle-5.6.4-all/ankdp27end7byghfw1q2sw75f/gradle-5.6.4-all.zip to /builds/sebasira/android-module-boilerplate/.gradle/wrapper/dists/gradle-5.6.4-all/ankdp27end7byghfw1q2sw75f
Set executable permissions for: /builds/sebasira/android-module-boilerplate/.gradle/wrapper/dists/gradle-5.6.4-all/ankdp27end7byghfw1q2sw75f/gradle-5.6.4/bin/gradle
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/5.6.4/userguide/gradle_daemon.html.
Daemon will be stopped at the end of the build stopping after processing
Cannot publish pom for project ':app' since it does not contain the Maven plugin install task and task ':app:artifactoryPublish' does not specify a custom pom path.
No publish configurations specified for project ':' and the default 'archives' configuration does not exist.
Compatible side by side NDK version was not found for android.ndkVersion '21.3.6528147'
Checking the license for package NDK (Side by side) 21.3.6528147 in /sdk/licenses
License for package NDK (Side by side) 21.3.6528147 accepted.
Preparing "Install NDK (Side by side) 21.3.6528147 (revision: 21.3.6528147)".
"Install NDK (Side by side) 21.3.6528147 (revision: 21.3.6528147)" ready.
Installing NDK (Side by side) 21.3.6528147 in /sdk/ndk/21.3.6528147
"Install NDK (Side by side) 21.3.6528147 (revision: 21.3.6528147)" complete.
"Install NDK (Side by side) 21.3.6528147 (revision: 21.3.6528147)" finished.
Checking the license for package CMake 3.6.4111459 in /sdk/licenses
License for package CMake 3.6.4111459 accepted.
Preparing "Install CMake 3.6.4111459 (revision: 3.6.4111459)".
"Install CMake 3.6.4111459 (revision: 3.6.4111459)" ready.
Installing CMake 3.6.4111459 in /sdk/cmake/3.6.4111459
"Install CMake 3.6.4111459 (revision: 3.6.4111459)" complete.
"Install CMake 3.6.4111459 (revision: 3.6.4111459)" finished.
Checking the license for package Android SDK Build-Tools 28.0.3 in /sdk/licenses
License for package Android SDK Build-Tools 28.0.3 accepted.
Preparing "Install Android SDK Build-Tools 28.0.3 (revision: 28.0.3)".
"Install Android SDK Build-Tools 28.0.3 (revision: 28.0.3)" ready.
Installing Android SDK Build-Tools 28.0.3 in /sdk/build-tools/28.0.3
"Install Android SDK Build-Tools 28.0.3 (revision: 28.0.3)" complete.
"Install Android SDK Build-Tools 28.0.3 (revision: 28.0.3)" finished.
Checking the license for package Android SDK Platform 29 in /sdk/licenses
License for package Android SDK Platform 29 accepted.
Preparing "Install Android SDK Platform 29 (revision: 5)".
"Install Android SDK Platform 29 (revision: 5)" ready.
Installing Android SDK Platform 29 in /sdk/platforms/android-29
"Install Android SDK Platform 29 (revision: 5)" complete.
"Install Android SDK Platform 29 (revision: 5)" finished.
> Task :clean UP-TO-DATE
> Task :app:externalNativeBuildCleanDebug
> Task :app:externalNativeBuildCleanRelease
> Task :app:clean UP-TO-DATE
> Task :app:preBuild UP-TO-DATE
> Task :app:preReleaseBuild UP-TO-DATE
> Task :app:compileReleaseAidl NO-SOURCE
> Task :app:compileReleaseRenderscript NO-SOURCE
> Task :app:checkReleaseManifest
> Task :app:generateReleaseBuildConfig
> Task :app:generateReleaseResValues
> Task :app:generateReleaseResources
> Task :app:packageReleaseResources
> Task :app:parseReleaseLibraryResources
> Task :app:processReleaseManifest
> Task :app:generateReleaseRFile
> Task :app:javaPreCompileRelease

> Task :app:compileReleaseJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :app:extractReleaseAnnotations
> Task :app:mergeReleaseGeneratedProguardFiles
> Task :app:mergeReleaseConsumerProguardFiles
> Task :app:mergeReleaseShaders
> Task :app:compileReleaseShaders
> Task :app:generateReleaseAssets
> Task :app:packageReleaseAssets
> Task :app:packageReleaseRenderscript NO-SOURCE
> Task :app:prepareLintJarForPublish
> Task :app:processReleaseJavaRes NO-SOURCE
> Task :app:mergeReleaseJavaResource
> Task :app:transformClassesAndResourcesWithSyncLibJarsForRelease

> Task :app:generateJsonModelRelease
release|armeabi-v7a :-- Check for working C compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
release|armeabi-v7a :-- Check for working C compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -- works
release|armeabi-v7a :-- Detecting C compiler ABI info
release|armeabi-v7a :-- Detecting C compiler ABI info - done
release|armeabi-v7a :-- Detecting C compile features
release|armeabi-v7a :-- Detecting C compile features - done
release|armeabi-v7a :-- Check for working CXX compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
release|armeabi-v7a :-- Check for working CXX compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -- works
release|armeabi-v7a :-- Detecting CXX compiler ABI info
release|armeabi-v7a :-- Detecting CXX compiler ABI info - done
release|armeabi-v7a :-- Detecting CXX compile features
release|armeabi-v7a :-- Detecting CXX compile features - done
release|armeabi-v7a :-- Configuring done
release|armeabi-v7a :-- Generating done
release|armeabi-v7a :-- Build files have been written to: /builds/sebasira/android-module-boilerplate/app/.cxx/cmake/release/armeabi-v7a
release|arm64-v8a :-- Check for working C compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
release|arm64-v8a :-- Check for working C compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -- works
release|arm64-v8a :-- Detecting C compiler ABI info
release|arm64-v8a :-- Detecting C compiler ABI info - done
release|arm64-v8a :-- Detecting C compile features
release|arm64-v8a :-- Detecting C compile features - done
release|arm64-v8a :-- Check for working CXX compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
release|arm64-v8a :-- Check for working CXX compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -- works
release|arm64-v8a :-- Detecting CXX compiler ABI info
release|arm64-v8a :-- Detecting CXX compiler ABI info - done
release|arm64-v8a :-- Detecting CXX compile features
release|arm64-v8a :-- Detecting CXX compile features - done
release|arm64-v8a :-- Configuring done
release|arm64-v8a :-- Generating done
release|arm64-v8a :-- Build files have been written to: /builds/sebasira/android-module-boilerplate/app/.cxx/cmake/release/arm64-v8a
release|x86 :-- Check for working C compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
release|x86 :-- Check for working C compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -- works
release|x86 :-- Detecting C compiler ABI info
release|x86 :-- Detecting C compiler ABI info - done
release|x86 :-- Detecting C compile features
release|x86 :-- Detecting C compile features - done
release|x86 :-- Check for working CXX compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
release|x86 :-- Check for working CXX compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -- works
release|x86 :-- Detecting CXX compiler ABI info
release|x86 :-- Detecting CXX compiler ABI info - done
release|x86 :-- Detecting CXX compile features
release|x86 :-- Detecting CXX compile features - done
release|x86 :-- Configuring done
release|x86 :-- Generating done
release|x86 :-- Build files have been written to: /builds/sebasira/android-module-boilerplate/app/.cxx/cmake/release/x86
release|x86_64 :-- Check for working C compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
release|x86_64 :-- Check for working C compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -- works
release|x86_64 :-- Detecting C compiler ABI info
release|x86_64 :-- Detecting C compiler ABI info - done
release|x86_64 :-- Detecting C compile features
release|x86_64 :-- Detecting C compile features - done
release|x86_64 :-- Check for working CXX compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++
release|x86_64 :-- Check for working CXX compiler: /sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -- works
release|x86_64 :-- Detecting CXX compiler ABI info
release|x86_64 :-- Detecting CXX compiler ABI info - done
release|x86_64 :-- Detecting CXX compile features
release|x86_64 :-- Detecting CXX compile features - done
release|x86_64 :-- Configuring done
release|x86_64 :-- Generating done
release|x86_64 :-- Build files have been written to: /builds/sebasira/android-module-boilerplate/app/.cxx/cmake/release/x86_64

> Task :app:externalNativeBuildRelease
Build boilerplate-native-lib_armeabi-v7a
[1/2] Building CXX object CMakeFiles/boilerplate-native-lib.dir/native-lib.cpp.o
[2/2] Linking CXX shared library /builds/sebasira/android-module-boilerplate/app/build/intermediates/cmake/release/obj/armeabi-v7a/libboilerplate-native-lib.so
Build boilerplate-native-lib_arm64-v8a
[1/2] Building CXX object CMakeFiles/boilerplate-native-lib.dir/native-lib.cpp.o
[2/2] Linking CXX shared library /builds/sebasira/android-module-boilerplate/app/build/intermediates/cmake/release/obj/arm64-v8a/libboilerplate-native-lib.so
Build boilerplate-native-lib_x86
[1/2] Building CXX object CMakeFiles/boilerplate-native-lib.dir/native-lib.cpp.o
[2/2] Linking CXX shared library /builds/sebasira/android-module-boilerplate/app/build/intermediates/cmake/release/obj/x86/libboilerplate-native-lib.so
Build boilerplate-native-lib_x86_64
[1/2] Building CXX object CMakeFiles/boilerplate-native-lib.dir/native-lib.cpp.o
[2/2] Linking CXX shared library /builds/sebasira/android-module-boilerplate/app/build/intermediates/cmake/release/obj/x86_64/libboilerplate-native-lib.so

> Task :app:mergeReleaseJniLibFolders
> Task :app:mergeReleaseNativeLibs
> Task :app:stripReleaseDebugSymbols
> Task :app:transformNativeLibsWithSyncJniLibsForRelease
> Task :app:bundleReleaseAar
> Task :app:uploadArchives
> Task :app:artifactoryPublish
> Task :artifactoryPublish
> Task :extractModuleInfo
> Task :app:extractModuleInfo
[pool-3-thread-1] Deploying artifact: <here was the URL of my artifact, in artifactory>
[pool-3-thread-1] Deploying artifact:  <here was the URL of my artifact, in artifactory>
> Task :artifactoryDeploy

Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.6.4/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 3m 4s
35 actionable tasks: 33 executed, 2 up-to-date
section_end:1603669575:build_script
section_start:1603669575:after_script
section_end:1603669577:after_script
section_start:1603669577:archive_cache
section_end:1603669578:archive_cache
section_start:1603669578:upload_artifacts_on_success
section_end:1603669580:upload_artifacts_on_success
Job succeeded

And when it's not deployed:
------------------------------------------------------------
Gradle 5.6.4
------------------------------------------------------------

Build time:   2019-11-01 20:42:00 UTC
Revision:     dd870424f9bd8e195d614dc14bb140f43c22da98

Kotlin:       1.3.41
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.14 compiled on March 12 2019
JVM:          11.0.8 (Ubuntu 11.0.8+10-post-Ubuntu-0ubuntu120.04)
OS:           Linux 4.4.0-190-generic amd64

$ curl -fL https://getcli.jfrog.io | sh # collapsed multi-line command
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   178  100   178    0     0    455      0 --:--:-- --:--:-- --:--:--   455

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  1344  100  1344    0     0   3147      0 --:--:-- --:--:-- --:--:--  187k
Downloading the latest version of JFrog CLI...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

100 19.0M  100 19.0M    0     0  26.0M      0 --:--:-- --:--:-- --:--:-- 26.0M
[Info] Encrypting password...
Server ID: Default-Server
Url: <myArtifactoryURL>
User: <myArtifactoryUser>
Password: <myPass>
Default:  true

$ sed -i 's,GRADLE_REPO_KEY,'"$GRADLE_REPO_KEY"',g' configuration.yaml
$ ./jfrog rt gradle-config --use-wrapper=true --repo-resolve=$GRADLE_REPO_KEY --server-id-resolve=Default-Server --repo-deploy=$GRADLE_REPO_KEY --server-id-deploy=Default-Server # collapsed multi-line command
[Info] gradle build config successfully created.
[Info] Downloading bintray/jcenter/org/jfrog/buildinfo/build-info-extractor-gradle/4.18.0/build-info-extractor-gradle-4.18.0-uber.jar
[Info] Downloaded 1 artifact.
[Info] Running gradle command: ./gradlew --init-script /root/.jfrog/dependencies/gradle/4.18.0/gradle.init clean artifactoryPublish -b build.gradle
Downloading https://services.gradle.org/distributions/gradle-5.6.4-all.zip
.....................................................................................................................................
Unzipping /builds/sebasira/android-module-boilerplate/.gradle/wrapper/dists/gradle-5.6.4-all/ankdp27end7byghfw1q2sw75f/gradle-5.6.4-all.zip to /builds/sebasira/android-module-boilerplate/.gradle/wrapper/dists/gradle-5.6.4-all/ankdp27end7byghfw1q2sw75f
Set executable permissions for: /builds/sebasira/android-module-boilerplate/.gradle/wrapper/dists/gradle-5.6.4-all/ankdp27end7byghfw1q2sw75f/gradle-5.6.4/bin/gradle
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/5.6.4/userguide/gradle_daemon.html.
Daemon will be stopped at the end of the build stopping after processing
> Task :clean UP-TO-DATE

> Task :app:externalNativeBuildCleanDebug
Compatible side by side NDK version was not found for android.ndkVersion '21.3.6528147'
Checking the license for package NDK (Side by side) 21.3.6528147 in /sdk/licenses
License for package NDK (Side by side) 21.3.6528147 accepted.
Preparing "Install NDK (Side by side) 21.3.6528147 (revision: 21.3.6528147)".
"Install NDK (Side by side) 21.3.6528147 (revision: 21.3.6528147)" ready.
Installing NDK (Side by side) 21.3.6528147 in /sdk/ndk/21.3.6528147
"Install NDK (Side by side) 21.3.6528147 (revision: 21.3.6528147)" complete.
"Install NDK (Side by side) 21.3.6528147 (revision: 21.3.6528147)" finished.
Checking the license for package CMake 3.6.4111459 in /sdk/licenses
License for package CMake 3.6.4111459 accepted.
Preparing "Install CMake 3.6.4111459 (revision: 3.6.4111459)".
"Install CMake 3.6.4111459 (revision: 3.6.4111459)" ready.
Installing CMake 3.6.4111459 in /sdk/cmake/3.6.4111459
"Install CMake 3.6.4111459 (revision: 3.6.4111459)" complete.
"Install CMake 3.6.4111459 (revision: 3.6.4111459)" finished.

> Task :app:externalNativeBuildCleanRelease
> Task :app:clean UP-TO-DATE
> Task :app:artifactoryPublish
> Task :artifactoryPublish
> Task :extractModuleInfo
> Task :app:extractModuleInfo
> Task :artifactoryDeploy

BUILD SUCCESSFUL in 2m 53s
9 actionable tasks: 7 executed, 2 up-to-date
section_end:1604009769:build_script
section_start:1604009769:after_script
section_end:1604009771:after_script
section_start:1604009771:archive_cache
section_end:1604009772:archive_cache
section_start:1604009772:upload_artifacts_on_success
section_end:1604009774:upload_artifacts_on_success
Job succeeded

Versions

JFrog CLI version: latest (v1.40.0)
JFrog CLI operating system: Ubuntu
Artifactory Version: 6.10.1 rev 61001900

Additional context
You will notice it uses Gradle v5.6.4. I've also update it to Gradle v6.7 with the same result, and the went back to v5.6.4 because was the last that suceed.
One thing I've notice from the below logs is that the jfrog-cli download size is different and that's what lead me to think that this happens on the latest version.
I try to set a previous version when downloading but it gives me another error:
[32;1m$ curl -fL https://getcli.jfrog.io | sh -s v1.39.7 # collapsed multi-line command
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   178  100   178    0     0    552      0 --:--:-- --:--:-- --:--:--   552

100  1344  100  1344    0     0   3622      0 --:--:-- --:--:-- --:--:--  3622
Downloading version v1.39.7 of JFrog CLI...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100    85  100    85    0     0    129      0 --:--:-- --:--:-- --:--:--   128
./jfrog: line 1: {message:Could not find artifact with path 'v1.39.7/jfrog-cli-linux-amd64/jfrog'}: No such file or directory
section_end:1604010794:build_script
section_start:1604010794:after_script
section_end:1604010795:after_script
section_start:1604010795:upload_artifacts_on_failure
section_end:1604010797:upload_artifacts_on_failure
ERROR: Job failed: exit code 1

Maybe I'm just miss-using the cli with this new version, if that's the case, can you guide me?
Thanks in advance!

I can confirm that this only happens to Android Libraries (that produces .aar artifacts). I've tested with 3 different modules and all of them behave the same way. Two of them had not changed since the last successful deploy and when trying to upload a dummy verison (with only changing the version and nothing else, just to test the deployment) they were not deployed.
Also test a Java library and was successfully deployed to the same Artifactory server with the same GitLab CI/CD script.

Taking a closer look into the logs I've posted, I've notice that JFrog Gradle plugin (for Build Info extraction and Artifactory publishing) has also change and has been updated 3 days ago.
When artifacts are not deployed (maybe I should say generated, becuase I think they are not even generated and that why they are not deployed)
[Info] gradle build config successfully created.
[Info] Downloading bintray/jcenter/org/jfrog/buildinfo/build-info-extractor-gradle/4.18.0/build-info-extractor-gradle-4.18.0-uber.jar
[Info] Downloaded 1 artifact.
[Info] Running gradle command: ./gradlew --init-script /root/.jfrog/dependencies/gradle/4.18.0/gradle.init clean artifactoryPublish -b build.gradle

And when it was working:
Info] gradle build config successfully created.
[Info] Downloading bintray/jcenter/org/jfrog/buildinfo/build-info-extractor-gradle/4.15.2/build-info-extractor-gradle-4.15.2-uber.jar
[Info] Downloaded 1 artifact.
[Info] Running gradle command: ./gradlew --init-script /root/.jfrog/dependencies/gradle/4.15.2/gradle.init clean artifactoryPublish -b build.gradle

Thanks for reporting this issue, @sebasira
You diagnostic is correct. We did update the Gradle extractor version in the latest JFrog CLI release. Apologize for this issue.
The last Gradle plugin releases includes many bug fixes and new features and we think it should be in the latest JFrog CLI.
As a workaround you can use JFrog CLI 1.39.7 for now.
To speed up the fix, I created https://github.com/jfrog/build-info/pull/407.
However in order to make sure all cases have been covered, we would appreciate additional information from you:

In your build.gradle file, do you apply explicitly the Gradle Artifactory plugin? (apply plugin: 'com.jfrog.artifactory')
How do you mention your published artifacts in the build.gradle? Do you specify the publications you wish to publish , for example:

publishing {
  publications {
    app(MavenPublication) {
       groupId = group
       artifactId = project.getName()
       version = currentVersion
       artifact("$buildDir/outputs/apk/release/app-release-unsigned.apk")
     }
  }
}

If you can, creating a minimal reproducible example will help a lot.

Thanks in advance.

@yahavi thank you for looking into this and for publishing a PR.
I'l answer your questions with the same number.
1- No. I 'm actually not using the Artifactory Gradle Plugin in my build.gradle. I relay in the jFrog CLI and GitLab CI/CD Pipeline to deploy. The jFrog CLI command uses the artifactory gradle. This is part of the YAML script from the first post where I use jFrog CLI
  ./jfrog rt gradle-config --use-wrapper=true --repo-resolve=$GRADLE_REPO_KEY --server-id-resolve=Default-Server --repo-deploy=$GRADLE_REPO_KEY --server-id-deploy=Default-Server
  ./jfrog rt gradle clean artifactoryPublish -b build.gradle --build-name=$ARTIFACT_NAME --build-number=$CI_JOB_ID

My build.gradle file knows nothing about the Artifactory Gradle Plugin. Here it's a simplify version of it:
apply plugin: 'com.android.library'

// This is what ArtifactoyyPublish task (in GitLab CI/CD Pipeline) uses to determine the PATH and VERSION of the uploaded artifact
group = 'ar.com.sebasira'
version = '6.3.7'

project.archivesBaseName = rootProject.name

android {

    compileSdkVersion 29
    defaultConfig {
        minSdkVersion 29
        targetSdkVersion 29
        versionName project.version
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"

        vectorDrawables {
            useSupportLibrary true
        }

        externalNativeBuild {
            cmake {
                cppFlags "-frtti -fexceptions"
            }
        }
    }

    buildTypes {
        debug {
            minifyEnabled false
        }

        release {
            minifyEnabled false
            consumerProguardFiles 'proguard-my-lib-rules.pro'
        }
    }

    libraryVariants.all { variant ->
        variant.outputs.all {
            outputFileName = "${rootProject.name}-${defaultConfig.versionName}.aar"
        }
    }

    externalNativeBuild {
        cmake {
            path "src/main/cpp/CMakeLists.txt"
        }
    }
}

repositories {
    maven {
        url '<my-artifactory-repo>'
    }
}

dependencies {
    // All dependencies goes here
}

2- I think the answer to this question is also in the above answer. Look at this part of my build-gradle
 libraryVariants.all { variant ->
        variant.outputs.all {
            outputFileName = "${rootProject.name}-${defaultConfig.versionName}.aar"
        }
    }

I also have in settings.gradle
include ':app'
rootProject.name='my-cool-library'

With this info (and the versions from the first lines of the build.gradle file) it will generate an artifact with this name:

my-cool-library-6.3.7.aar

And this line from the build.gradle file was very important for the naming (I don't remember exavtly why, but I got issues without it):
project.archivesBaseName = rootProject.name

And this is my full GitLab CI/CD YAML script (with only the deploy stage):
image: jangrewe/gitlab-ci-android

before_script:
  - export GRADLE_USER_HOME=$(pwd)/.gradle
  - chmod +x ./gradlew

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - .gradle/

variables:
  GRADLE_VERSION: "6.7"
  ARTIFACT_NAME: "my-cool-library"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - deploy

.connect_artifactory: &connect_artifactory |
  curl -fL https://getcli.jfrog.io | sh
  ./jfrog rt config --url=$ARTIFACTORY_URL --user=$ARTIFACTORY_USER --password=$ARTIFACTORY_PASS
  ./jfrog rt c show

.upload_artifact: &upload_artifact |
  ./jfrog rt gradle-config --use-wrapper=true --repo-resolve=$GRADLE_REPO_KEY --server-id-resolve=Default-Server --repo-deploy=$GRADLE_REPO_KEY --server-id-deploy=Default-Server
  ./jfrog rt gradle clean artifactoryPublish -b build.gradle --build-name=$ARTIFACT_NAME --build-number=$CI_JOB_ID

.install_gradle: &install_gradle |
  curl -L https://services.gradle.org/distributions/gradle-$GRADLE_VERSION-all.zip -o gradle.zip
  unzip -q gradle.zip
  export GRADLE_HOME=$(pwd)/gradle-$GRADLE_VERSION
  export PATH=${GRADLE_HOME}/bin:${PATH}
  echo $GRADLE_HOME
  echo $PATH
  gradle -v

publish:
  stage: deploy
  cache: {}
  script:
    # Download and Install Gradle
    - *install_gradle
    # Connect to JFrog Artifactory
    - *connect_artifactory
    # Replace the repository name in the configuration.yml to the correct one.
    - sed -i 's,GRADLE_REPO_KEY,'"$GRADLE_REPO_KEY"',g' configuration.yaml
    # Upload artifact to JFrog Artifactory
    - *upload_artifact

Notice that there is a variable name $ARTIFACT_NAME that MUST have the same name that my rootProject.name
3- About the minimal example, I would love to. The only problem is that my setup is very tight to my private GitLab Server and also a private Artifactory Server. I can create a dummy Android Library but I would need a public GitLab repo to post it wher eI can configure the CI/CD to deploy to a public Artifactory Server.
And finally, you said:

As a workaround you can use JFrog CLI 1.39.7 for now.

How can achieve that? I've try this:
 curl -fL https://getcli.jfrog.io | sh -s v1.39.7

but it will give me this output:
[32;1m$ curl -fL https://getcli.jfrog.io | sh -s v1.39.7 # collapsed multi-line command
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   178  100   178    0     0    552      0 --:--:-- --:--:-- --:--:--   552

100  1344  100  1344    0     0   3622      0 --:--:-- --:--:-- --:--:--  3622
Downloading version v1.39.7 of JFrog CLI...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100    85  100    85    0     0    129      0 --:--:-- --:--:-- --:--:--   128
./jfrog: line 1: {message:Could not find artifact with path 'v1.39.7/jfrog-cli-linux-amd64/jfrog'}: No such file or directory
section_end:1604010794:build_script
section_start:1604010794:after_script
section_end:1604010795:after_script
section_start:1604010795:upload_artifacts_on_failure
section_end:1604010797:upload_artifacts_on_failure
ERROR: Job failed: exit code 1

This is the relevant part:

./jfrog: line 1: {message:Could not find artifact with path 'v1.39.7/jfrog-cli-linux-amd64/jfrog'}: No such file or directory

I also try with all other versions, even in my local computer and have the same error when I run the curl command in the terminal. It seems like there are no binaries for older versions just the latest one

@sebasira
You can find all available CLI versions in Bintray: https://bintray.com/jfrog/jfrog-cli-go.
For example, here is the link for Linux amd64: https://bintray.com/jfrog/jfrog-cli-go/download_file?file_path=1.39.7%2Fjfrog-cli-linux-amd64%2Fjfrog

Thank you! I can now deploy library updates with the older version of the jFrog CLI. I'll put the workaround here in case anyone stumble upon this:
In my previous GitLab CI/CD YAML script need to make the change in the .connect_artifactory sub-script. Replace:
  curl -fL https://getcli.jfrog.io | sh

with this:
  curl -L https://bintray.com/jfrog/jfrog-cli-go/download_file?file_path=1.39.7%2Fjfrog-cli-linux-amd64%2Fjfrog --output jfrog
  chmod +x jfrog

Notice that the URL points to the linux-amd64 distribution, change that url according to your OS.
I'll keep waiting for the official fix. Thank you!

@sebasira after a deeper look at your curl command, I managed to download version 1.39.7 of the CLI with the getCli:
curl -fL https://getcli.jfrog.io | sh -s 1.39.7

I just removed the v before the version.
By the way - using the getCli is the preferred way since it automatically detects the operating system and it is more resilient to changes.
We will seriously investigate and will search for "out of the box" solution for Android users. We will also keep you updated here.

Thank you very much!
I also think the best way is using getCLI script. I'll update my scripts.
If I can be of any assistance to test for Android libraries, it would be my pleasure.
About the Android sample project to reproduce this, I was thinking that the GitLab repo is not needed. I can create a sample Android project, with a bash script (emulating the YAML script of GitLab) and it should be working in the same way. You would only need to change some variables to point to your Artifactory server URL with your credentials.

Thanks, @sebasira
A minimal sample Android project would be appreciated. Most interesting are the build.gradle file and the information on what do you expects to be uploaded by default (apk? aar?).
If you want to contribute code, you can upload the sample here: https://github.com/jfrog/project-examples/tree/master/gradle-examples as gradle-android-example-ci-server by creating a pull request. Otherwise, a simple GitHub repository will do.

Hi!
It's been a long time... I've created a sample library that so you guys can work with it and submitted as a PR as instructed.
I'd like to remark that the extension  of the artifact is .aar, and you can find in the build.gradle file how I rename the artifact to the name I want. I'm guessing the extension is the issue.
I'm here again with this issue because I was using a previous version of jFrog CLI  but now I can no longer use it because it seems that it uses an old artifact that's no longer available:
[Info] gradle build config successfully created.
[Info] Downloading bintray/jcenter/org/jfrog/buildinfo/build-info-extractor-gradle/4.15.2/build-info-extractor-gradle-4.15.2-uber.jar
[Error] 403 Forbidden
ERROR: Job failed: exit code 1

For what is worth, I have more information after adding INFO logging level to the script:
> Task :app:assembleRelease
Skipping task ':app:assembleRelease' as it has no actions.
:app:assembleRelease (Thread[Daemon worker,5,main]) completed. Took 0.001 secs.
:app:artifactoryPublish (Thread[Daemon worker,5,main]) started.
> Task :app:artifactoryPublish
Caching disabled for task ':app:artifactoryPublish' because:
  Build cache is disabled
Task ':app:artifactoryPublish' is not up-to-date because:
  Task has not declared any outputs despite executing actions.
:app:artifactoryPublish (Thread[Daemon worker,5,main]) completed. Took 0.003 secs.
:artifactoryPublish (Thread[Daemon worker,5,main]) started.
> Task :artifactoryPublish
Caching disabled for task ':artifactoryPublish' because:
  Build cache is disabled
Task ':artifactoryPublish' is not up-to-date because:
  Task has not declared any outputs despite executing actions.
:artifactoryPublish (Thread[Daemon worker,5,main]) completed. Took 0.003 secs.
:extractModuleInfo (Thread[Daemon worker,5,main]) started.
> Task :extractModuleInfo
Caching disabled for task ':extractModuleInfo' because:
  Build cache is disabled
Task ':extractModuleInfo' is not up-to-date because:
  Task.upToDateWhen is false.
:extractModuleInfo (Thread[Daemon worker,5,main]) completed. Took 0.546 secs.
:app:extractModuleInfo (Thread[Daemon worker,5,main]) started.
> Task :app:extractModuleInfo
Caching disabled for task ':app:extractModuleInfo' because:
  Build cache is disabled
Task ':app:extractModuleInfo' is not up-to-date because:
  Task.upToDateWhen is false.
Artifacts for configuration 'androidTestAnnotationProcessor' were not all resolved, skipping
Artifacts for configuration 'androidTestApi' were not all resolved, skipping
Artifacts for configuration 'androidTestCompile' were not all resolved, skipping
Artifacts for configuration 'androidTestCompileOnly' were not all resolved, skipping
Artifacts for configuration 'androidTestDebugAnnotationProcessor' were not all resolved, skipping
Artifacts for configuration 'androidTestDebugApi' were not all resolved, skipping
Artifacts for configuration 'androidTestDebugCompile' were not all resolved, skipping
Artifacts for configuration 'androidTestDebugCompileOnly' were not all resolved, skipping
Artifacts for configuration 'androidTestDebugImplementation' were not all resolved, skipping
Artifacts for configuration 'androidTestDebugProvided' were not all resolved, skipping
Artifacts for configuration 'androidTestDebugPublish' were not all resolved, skipping
Artifacts for configuration 'androidTestDebugRuntimeOnly' were not all resolved, skipping
Artifacts for configuration 'androidTestDebugWearApp' were not all resolved, skipping
Artifacts for configuration 'androidTestImplementation' were not all resolved, skipping
Artifacts for configuration 'androidTestProvided' were not all resolved, skipping
Artifacts for configuration 'androidTestPublish' were not all resolved, skipping
Artifacts for configuration 'androidTestReleaseAnnotationProcessor' were not all resolved, skipping
Artifacts for configuration 'androidTestReleaseApi' were not all resolved, skipping
Artifacts for configuration 'androidTestReleaseCompile' were not all resolved, skipping
Artifacts for configuration 'androidTestReleaseCompileOnly' were not all resolved, skipping
Artifacts for configuration 'androidTestReleaseImplementation' were not all resolved, skipping
Artifacts for configuration 'androidTestReleaseProvided' were not all resolved, skipping
Artifacts for configuration 'androidTestReleasePublish' were not all resolved, skipping
Artifacts for configuration 'androidTestReleaseRuntimeOnly' were not all resolved, skipping
Artifacts for configuration 'androidTestReleaseWearApp' were not all resolved, skipping
Artifacts for configuration 'androidTestRuntimeOnly' were not all resolved, skipping
Artifacts for configuration 'androidTestUtil' were not all resolved, skipping
Artifacts for configuration 'androidTestWearApp' were not all resolved, skipping
Artifacts for configuration 'annotationProcessor' were not all resolved, skipping
Artifacts for configuration 'api' were not all resolved, skipping
Artifacts for configuration 'archives' were not all resolved, skipping
Artifacts for configuration 'compile' were not all resolved, skipping
Artifacts for configuration 'compileOnly' were not all resolved, skipping
Artifacts for configuration 'coreLibraryDesugaring' were not all resolved, skipping
Artifacts for configuration 'debugAllApiPublication' were not all resolved, skipping
Artifacts for configuration 'debugAllRuntimePublication' were not all resolved, skipping
Artifacts for configuration 'debugAndroidTestAnnotationProcessorClasspath' were not all resolved, skipping
Artifacts for configuration 'debugAndroidTestCompileClasspath' were not all resolved, skipping
Artifacts for configuration 'debugAndroidTestRuntimeClasspath' were not all resolved, skipping
Artifacts for configuration 'debugAnnotationProcessor' were not all resolved, skipping
Artifacts for configuration 'debugAnnotationProcessorClasspath' were not all resolved, skipping
Artifacts for configuration 'debugApi' were not all resolved, skipping
Artifacts for configuration 'debugApiElements' were not all resolved, skipping
Artifacts for configuration 'debugApiPublication' were not all resolved, skipping
Artifacts for configuration 'debugCompile' were not all resolved, skipping
Artifacts for configuration 'debugCompileClasspath' were not all resolved, skipping
Artifacts for configuration 'debugCompileOnly' were not all resolved, skipping
Artifacts for configuration 'debugImplementation' were not all resolved, skipping
Artifacts for configuration 'debugProvided' were not all resolved, skipping
Artifacts for configuration 'debugPublish' were not all resolved, skipping
Artifacts for configuration 'debugRuntimeClasspath' were not all resolved, skipping
Artifacts for configuration 'debugRuntimeElements' were not all resolved, skipping
Artifacts for configuration 'debugRuntimeOnly' were not all resolved, skipping
Artifacts for configuration 'debugRuntimePublication' were not all resolved, skipping
Artifacts for configuration 'debugUnitTestAnnotationProcessorClasspath' were not all resolved, skipping
Artifacts for configuration 'debugUnitTestCompileClasspath' were not all resolved, skipping
Artifacts for configuration 'debugUnitTestRuntimeClasspath' were not all resolved, skipping
Artifacts for configuration 'debugWearApp' were not all resolved, skipping
Artifacts for configuration 'default' were not all resolved, skipping
Artifacts for configuration 'implementation' were not all resolved, skipping
Artifacts for configuration 'jacocoAgent' were not all resolved, skipping
Artifacts for configuration 'jacocoAnt' were not all resolved, skipping
Artifacts for configuration 'lintChecks' were not all resolved, skipping
Artifacts for configuration 'provided' were not all resolved, skipping
Artifacts for configuration 'publish' were not all resolved, skipping
Artifacts for configuration 'releaseAllApiPublication' were not all resolved, skipping
Artifacts for configuration 'releaseAllRuntimePublication' were not all resolved, skipping
Artifacts for configuration 'releaseAnnotationProcessor' were not all resolved, skipping
Artifacts for configuration 'releaseApi' were not all resolved, skipping
Artifacts for configuration 'releaseApiElements' were not all resolved, skipping
Artifacts for configuration 'releaseApiPublication' were not all resolved, skipping
Artifacts for configuration 'releaseCompile' were not all resolved, skipping
Artifacts for configuration 'releaseCompileOnly' were not all resolved, skipping
Artifacts for configuration 'releaseImplementation' were not all resolved, skipping
Artifacts for configuration 'releaseProvided' were not all resolved, skipping
Artifacts for configuration 'releasePublish' were not all resolved, skipping
Artifacts for configuration 'releaseRuntimeElements' were not all resolved, skipping
Artifacts for configuration 'releaseRuntimeOnly' were not all resolved, skipping
Artifacts for configuration 'releaseRuntimePublication' were not all resolved, skipping
Artifacts for configuration 'releaseUnitTestAnnotationProcessorClasspath' were not all resolved, skipping
Artifacts for configuration 'releaseUnitTestCompileClasspath' were not all resolved, skipping
Artifacts for configuration 'releaseUnitTestRuntimeClasspath' were not all resolved, skipping
Artifacts for configuration 'releaseWearApp' were not all resolved, skipping
Artifacts for configuration 'runtimeOnly' were not all resolved, skipping
Artifacts for configuration 'testAnnotationProcessor' were not all resolved, skipping
Artifacts for configuration 'testApi' were not all resolved, skipping
Artifacts for configuration 'testCompile' were not all resolved, skipping
Artifacts for configuration 'testCompileOnly' were not all resolved, skipping
Artifacts for configuration 'testDebugAnnotationProcessor' were not all resolved, skipping
Artifacts for configuration 'testDebugApi' were not all resolved, skipping
Artifacts for configuration 'testDebugCompile' were not all resolved, skipping
Artifacts for configuration 'testDebugCompileOnly' were not all resolved, skipping
Artifacts for configuration 'testDebugImplementation' were not all resolved, skipping
Artifacts for configuration 'testDebugProvided' were not all resolved, skipping
Artifacts for configuration 'testDebugPublish' were not all resolved, skipping
Artifacts for configuration 'testDebugRuntimeOnly' were not all resolved, skipping
Artifacts for configuration 'testDebugWearApp' were not all resolved, skipping
Artifacts for configuration 'testImplementation' were not all resolved, skipping
Artifacts for configuration 'testProvided' were not all resolved, skipping
Artifacts for configuration 'testPublish' were not all resolved, skipping
Artifacts for configuration 'testReleaseAnnotationProcessor' were not all resolved, skipping
Artifacts for configuration 'testReleaseApi' were not all resolved, skipping
Artifacts for configuration 'testReleaseCompile' were not all resolved, skipping
Artifacts for configuration 'testReleaseCompileOnly' were not all resolved, skipping
Artifacts for configuration 'testReleaseImplementation' were not all resolved, skipping
Artifacts for configuration 'testReleaseProvided' were not all resolved, skipping
Artifacts for configuration 'testReleasePublish' were not all resolved, skipping
Artifacts for configuration 'testReleaseRuntimeOnly' were not all resolved, skipping
Artifacts for configuration 'testReleaseWearApp' were not all resolved, skipping
Artifacts for configuration 'testRuntimeOnly' were not all resolved, skipping
Artifacts for configuration 'testWearApp' were not all resolved, skipping
Artifacts for configuration 'wearApp' were not all resolved, skipping
:app:extractModuleInfo (Thread[Daemon worker,5,main]) completed. Took 2.012 secs.
:artifactoryDeploy (Thread[Daemon worker,5,main]) started.
> Task :artifactoryDeploy
Caching disabled for task ':artifactoryDeploy' because:
  Build cache is disabled
Task ':artifactoryDeploy' is not up-to-date because:
  Task has not declared any outputs despite executing actions.
:artifactoryDeploy (Thread[Daemon worker,5,main]) completed. Took 0.211 secs.
AAPT2 aapt2-4.2.1-7147631-linux Daemon #0: shutdown
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.8.3/userguide/command_line_interface.html#sec:command_line_warnings
BUILD SUCCESSFUL in 4m 13s
35 actionable tasks: 33 executed, 2 up-to-date
Job succeeded

@sebasira,
Thanks for the reproducer! We will look into it and hopefully will fix this issue soon.

@sebasira,
The JFrog CLI uses the maven-publish plugin to collect the publications in order to upload them to Artifactory.
I followed this guide to configure publications on Android: https://developer.android.com/studio/build/maven-publish-plugin
To make the reproducer work, you should define the requested publications.
I manage to publish test-library-name-1.1s.aar using the following steps:

Add the maven-publish plugin at the top of the file.
Add the following afterEvaluate clause:

afterEvaluate {
    publishing {
        publications {
            // Creates a Maven publication called "release".
            release(MavenPublication) {
                // Applies the component for the release build variant.
                from components.release
                artifactId = "${rootProject.name}"
                version = "${android.defaultConfig.versionName}"
            }
        }
    }
    // Add the new "release" publication to the list of publications to publish:
    artifactoryPublish {
        publications(publishing.publications.release)
    }
}

To make it work on my machine, I had to delete the applicationId "com.example.testlibrary". I'm not sure why but I got the following exception: Library projects cannot set applicationId.

Results:

➜  gradle-android-library-example-ci-server git:(master) ✗ jfrog rt gradle clean aP
[Info] Running gradle command: ./gradlew --init-script /Users/yahavi/.jfrog/dependencies/gradle/4.24.12/gradle.init clean aP
[pool-9-thread-1] Deploying artifact: http://<IP_ADDRESS>:8081/artifactory/libs-release-local/test-library-name/test-library-name/1.1s/test-library-name-1.1s.aar
[pool-9-thread-1] Deploying artifact: http://<IP_ADDRESS>:8081/artifactory/libs-release-local/test-library-name/test-library-name/1.1s/test-library-name-1.1s.module

Please let me know if that helped.

Thank you!
Yes this resolves the issue! You can close it if you like. I did not do it just in case you need or what additional information

About  the applicationId that was my bad! It's correct libraries can not set the applicationId. only applications can set the applicationId

I'm sorry... I have a new issue right now with this setup.
The problem is that I've got 2 stages on my CI configuration: test and deploy.
To speed up trial-and-error tests I was making, I've remove the test stage. And when I re-add it I've got an error in the test stage saying that:

Could not find method artifactoryPublish() for arguments [build_65alhtgfhtvsukhk0xe6ip8kl$_run_closure2$_closure18@48b7f5f3] on project ':app' of type org.gradle.api.Project.

I'm guessing that's because I'm not using the Artifactory Gradle Plugin and making the deployment via CI/CD. And in the test stage I do not have anything related to Artifactory.
Is there any way to solve this issue from the CI script and not using the gradle plugin?
I mean, the proposed changes are relaying on changes at the build.gradle file. I would like not to do so and just relay on the CI config file.
Till now I've been using jFrog CLI v1.39.7 and it's still working fine with the current configuration. So if it was (and still is) possible without the Gradle Plugin, I was hoping in keeping it that way.
Could it be possible to apply the same instructions/configuration provided in the afterEvaluate via the CLI.

@sebasira,
First, just to make sure that we are aligned, The JFrog CLI uses the Gradle Artifactory plugin to resolve dependencies and publish artifacts to Artifactory.
I think I can make it worked like in 1.39.7, but please note that this method is deprecated from the Gradle side, and may break in the future. Until this version, we used the old Gradle publish-configurations method, e.g. we extract the archives collected by the default archive configuration. You can read more about this method here.
Therefore we recommend you to define publications as instructed in the official Android guide: https://developer.android.com/studio/build/maven-publish-plugin
You can make it work using one of the 3 options:

Always run Gradle with the JFrog CLI:

jfrog rt gradle clean aP
jfrog rt gradle clean test

Always apply the Artifactory plugin:
Add this at the top of your build.gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "org.jfrog.buildinfo:build-info-extractor-gradle:latest.release"
    }
}

apply plugin: 'com.jfrog.artifactory'

Also, run jfrog rt gradle-config ... with --uses-plugin flag.

Optionally run the artifactoryPublish by wrapping it with pluginManager.withPlugin('com.jfrog.artifactory'):

pluginManager.withPlugin('com.jfrog.artifactory') {
    artifactoryPublish {
        publications(publishing.publications.release)
    }
}

Please let me know if that helped.

@yahavi thank you again!
Please excuse me, after re-reading my latest comment it was really a mess... That's because my head is a mess and sometimes I do not find the right words to express my self. I will try to make it as clear as I can.
Yes, I know jFrog CLI uses the Artifactory Gradle plugin. What I would like to avoid is to have any artifactory configuration in the build.gradle file. I would like that anything related to that will be present in the gitlab-ci.yml file. As it is today. Maybe with .aar files that's not possible and that's the whole center of the discussion.
If I'm following the conversation right, that's not possible and the afterEvaluate block is recommended/mandatory for .aar files. Am I right?
I don't have knowledge on groovy so I understand only a little about your suggestions. I think the one I like the most is the 3rd. Because what I understand is that it will only call the artifactoryPublish if the artifactory plugin is present, and that condition will only be met when at the deploy stage. Is that correct? I've try it and now all stages passes and artifacts are deployed.

@sebasira,
Your input helps us to learn and to keep improving. Thanks again!
You are right. Currently, there is no option to publish Android variants without publication and the Artifactory configuration in the build.gradle file. However, that doesn't mean that in the future there wouldn't be such options. The goal is to make these kinds of builds as simple as possible.
I'm glad to hear that the 3rd option worked for you.

it will only call the artifactoryPublish if the artifactory plugin is present, and that condition will only be met when at the deploy stage. Is that correct?

That's correct.
Please let us know if there are any more difficulties.

It's a pleasure!
Thank all of you for this tool that allows me to work and keep my dependencies available from a central repo!
If you ever need any help regarding Android in the future, I'll be glad to help.
Feel free to close this issue... I didn't what to do it my self because I believe you should take that decision.


[openssl] fix cross compilation with mingw

When cross compiling openssl on Linux, e.g.
./vcpkg install openssl:x64-mingw-dynamic
failed, because 'windres' was not found. The call to
openssl's Configure was missing the WINDRES environment
variable, which is needed in case it is prefixed. On
Ubuntu the binutils-mingw-w64-x86-64 package installed
it as /usr/bin/x86_64-w64-mingw32-windres.
Since mingw uses openssl-unix to build, it's worth mentioning
that the WINDRES env has no impact for non-mingw and is ignored
there.

Hi @d12fk
Thanks for your PR.
Could you please run vcpkg x-add-version openssl to update the version files?

Hi @d12fk
Thanks for your PR.
Could you please run vcpkg x-add-version openssl to update the version files?

Indeed, forgot to add them to the commit. Will update right away.

/azp run

The failures caused by popsift will be fixed by #17277.

/azp run

LGTM now, thanks for your fixing @d12fk.

/azp run

@d12fk
Could you please rebase to solve the conflicts?

@d12fk Can you test #18554? It seems to be fixed there

@d12fk, could you resolve the conflicts?

@d12fk Is work still being done for this PR?

@NancyLi1013 The fix is still needed. A merge conflict exists only in the versions. Can't you just push the version updates?


fix external get metadata

Signed-off-by: silenceper<EMAIL_ADDRESS>
fix external get metadata
Checklist

[x] Commits are signed with Developer Certificate of Origin (DCO)
[ ] Tests have been added
[ ] A PR is opened to update the documentation on https://github.com/kedacore/keda-docs
[ ] Changelog has been updated

Fixes #1157

Thanks @silenceper


How can I transparent gesture navigation in Android

Please help me, I need transparent gesture navigation bar background.

https://stackoverflow.com/a/69721972/6787582

Put this above MaterialApp
    SystemChrome.setSystemUIOverlayStyle(const SystemUiOverlayStyle(
      statusBarColor: Colors.transparent,
      systemNavigationBarColor: Colors.transparent,
    ));

@jakeump @Hari-07
Thanks, I have tried this options, but when I swipe screen from bottom, the black gesture navigation line appeared again.
Phone is XiaoMi 11 Ultra

@jakeump @Hari-07
Thanks, I have tried this options, but when I swipe screen from bottom, the black gesture navigation line appeared again.
Phone is XiaoMi 11 Ultra

The Xiaomi is the issue. It runs a different version of Android, so that code won't work. I don't have experience with Xiaomi, so I cannot help further.

@jakeump @Hari-07
Thanks, I have tried this options, but when I swipe screen from bottom, the black gesture navigation line appeared again.
Phone is XiaoMi 11 Ultra

The Xiaomi is the issue. It runs a different version of Android, so that code won't work. I don't have experience with Xiaomi, so I cannot help further.

I got it, thanks for help.

Please ask support questions on stackoverflow. Closing from here.


this page is breaking at loading state

https://dev--genetics-app.netlify.com/gene/ENSG00000198840

This fails because the gene is mitochondrial. See https://github.com/opentargets/genetics/issues/302.


update raiwidgets and responsibleai to erroranalysis 0.3.12

Description
update raiwidgets and responsibleai to erroranalysis 0.3.12
Checklist

[ ] I have added screenshots above for all UI changes.
[ ] I have added e2e tests for all UI changes.
[ ] Documentation was updated if it was needed.

Codecov Report

Merging #1786 (c3a0ad5) into main (2b9b16c) will decrease coverage by 8.55%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1786      +/-   ##
==========================================
- Coverage   91.81%   83.25%   -8.56%
==========================================
  Files          73       19      -54
  Lines        4127      406    -3721
==========================================
- Hits         3789      338    -3451
+ Misses        338       68     -270

Flag
Coverage Δ

unittests
83.25% <ø> (-8.56%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

responsibleai/responsibleai/_config/__init__.py

...erroranalysis/_internal/error_analyzer/__init__.py

...tabalanceanalysis/distribution_balance_measures.py

...ranalysis/erroranalysis/_internal/matrix_filter.py

...ai/databalanceanalysis/feature_balance_measures.py

...nalysis/erroranalysis/_internal/version_checker.py

...ai/responsibleai/_tools/counterfactual/__init__.py

erroranalysis/erroranalysis/_internal/metrics.py

...onsibleai/responsibleai/serialization_utilities.py

responsibleai/responsibleai/_tools/__init__.py

... and 44 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


[BUG] huggingface Connection Error

Hi,
I actually described the problem in the following issuecomment shortly, and I am submiting this issue as a new one for a more complete description.
https://github.com/OptimalScale/LMFlow/issues/431#issuecomment-1596966261
While initiating the SFT, I see a coonection error, which shows that it fails to fetch the models from huggingface.
I actually tried some ways like using VPN / not using VPN, but still fails.
It is quite weird that I managed to fetch the models from huggingface several days ago in the other project, which using the similar way as shown below:
tokenizer = transformers.AutoTokenizer.from_pretrained(
model_name_or_path,
cache_dir=output_dir,
model_max_length=per_device_train_batch_size,
padding_side="right",
use_fast=False,
)
I believe this problem could be temporary since the local internet could be blocked by some issue in the period, however, as you metioned in the above issue: https://github.com/OptimalScale/LMFlow/issues/431
if we can manually download the model and allocate it in a right format, the error could be bypassed the problem.
I am wondering what is the proper way to allocate the files?
For example, I am trying to fine tune bloom-560m:
https://huggingface.co/bigscience/bloom-560m/tree/main

Traceback (most recent call last):
  File "/venv/lib/python3.9/site-packages/transformers/utils/hub.py", line 417, in cached_file
    resolved_file = hf_hub_download(
  File "/venv/lib/python3.9/site-packages/huggingface_hub/utils/_validators.py", line 118, in _inner_fn
    return fn(*args, **kwargs)
  File "/venv/lib/python3.9/site-packages/huggingface_hub/file_download.py", line 1291, in hf_hub_download
    raise LocalEntryNotFoundError(
huggingface_hub.utils._errors.LocalEntryNotFoundError: Connection error, and we cannot find the requested files in the disk cache. Please try again or make sure your Internet connection is on.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/LMFlow/examples/finetune.py", line 70, in <module>
    main()
  File "/LMFlow/examples/finetune.py", line 55, in main
    model = AutoModel.get_model(model_args)
  File "/LMFlow/src/lmflow/models/auto_model.py", line 14, in get_model
    return HFDecoderModel(model_args, *args, **kwargs)
  File "/LMFlow/src/lmflow/models/hf_decoder_model.py", line 113, in __init__
    config = AutoConfig.from_pretrained(model_args.model_name_or_path, **config_kwargs)
  File "/venv/lib/python3.9/site-packages/transformers/models/auto/configuration_auto.py", line 944, in from_pretrained
    config_dict, unused_kwargs = PretrainedConfig.get_config_dict(pretrained_model_name_or_path, **kwargs)
  File "/venv/lib/python3.9/site-packages/transformers/configuration_utils.py", line 574, in get_config_dict
    config_dict, kwargs = cls._get_config_dict(pretrained_model_name_or_path, **kwargs)
  File "/venv/lib/python3.9/site-packages/transformers/configuration_utils.py", line 629, in _get_config_dict
    resolved_config_file = cached_file(
  File "/venv/lib/python3.9/site-packages/transformers/utils/hub.py", line 452, in cached_file
    raise EnvironmentError(
OSError: We couldn't connect to 'https://huggingface.co' to load this file, couldn't find it in the cached files and it looks like bigscience/bloom-560m is not the path to a directory containing a file named config.json.
Checkout your internet connection or see how to run the library in offline mode at 'https://huggingface.co/docs/transformers/installation#offline-mode'.
[2023-06-20 03:42:23,283] [INFO] [launch.py:318:sigkill_handler] Killing subprocess 606506
[2023-06-20 03:42:23,417] [INFO] [launch.py:318:sigkill_handler] Killing subprocess 606507
[2023-06-20 03:42:23,419] [INFO] [launch.py:318:sigkill_handler] Killing subprocess 606508
[2023-06-20 03:42:23,421] [INFO] [launch.py:318:sigkill_handler] Killing subprocess 606509
[2023-06-20 03:42:23,423] [INFO] [launch.py:318:sigkill_handler] Killing subprocess 606573
[2023-06-20 03:42:23,424] [INFO] [launch.py:318:sigkill_handler] Killing subprocess 606574
[2023-06-20 03:42:23,426] [ERROR] [launch.py:324:sigkill_handler] ['/venv/bin/python3.9', '-u', 'examples/finetune.py', '--local_rank=5', '--deepspeed', 'configs/ds_config_zero3.json', '--bf16', '--run_name', 'finetune_with_lora', '--model_name_or_path', 'bigscience/bloom-560m', '--num_train_epochs', '0.01', '--learning_rate', '2e-5', '--dataset_path', '/LMFlow/data/alpaca/train', '--per_device_train_batch_size', '1', '--per_device_eval_batch_size', '1', '--validation_split_percentage', '0', '--logging_steps', '20', '--block_size', '512', '--do_train', '--output_dir', 'output_models/finetune', '--overwrite_output_dir', '--ddp_timeout', '72000', '--save_steps', '5000', '--dataloader_num_workers', '1'] exits with return code = 1

Hi,
An easy way to resolve this issue is:

download the model and save it to your local path firstly
replace the model path with your local path

Then it does not need to download the model from huggingface.


Move from glide to dep

Glide docs recommend moving to dep.

Sweet if you could pick this up 👍

This is in master as of bebdabab9ff5e5514bee0df82719fabf2de7895d


Add WriteToStream method.

Add a method that outputs all data from a WaveProvider to a Stream.
Based off of CreateWaveFile, came in useful for me and thought it would be nice to include in NAudio.

nice idea, I wonder if it might be good to name it more similarly to CreateWaveFile maybe CreateWaveStream or something more descriptive like WriteWavFileToStream

Well the current method just appends the data to the end, but doesn't create a new stream, so WriteWavFileToStream would probably be more accurate.

ok let's go with that then

did you mean to close this PR? I can merge it now if you're done

closed by accident, whoops :) And yes I'm done.


Error running vitest: Error: error:0909006C:PEM routines:get_name:no start line

Describe the bug
Recently migrated to vite and vitest. Running vitest --config ./config/vite.config.ts --mode dev on a docker node:16 environment via gitlab ci fails with the following:
⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯
Error: error:0909006C:PEM routines:get_name:no start line
    at node:internal/tls/secure-context:69:13
    at Array.forEach (<anonymous>)
    at setCerts (node:internal/tls/secure-context:[67](https://gitlab.com/REDACTED/-/jobs/5169282099#L67):3)
    at configSecureContext (node:internal/tls/secure-context:156:5)
    at Object.createSecureContext (node:_tls_common:121:3)
    at Server.setSecureContext (node:_tls_wrap:1353:27)
    at Server (node:_tls_wrap:1212:8)
    at new Server (node:https:[73](REDACTED/-/jobs/5169282099#L73):3)
    at createServer (node:https:109:10)
    at createWebSocketServer (file:///builds/REDACTED/node_modules/vite/dist/node/chunks/dep-df561101.js:61730:28) {
  library: 'PEM routines',
  function: 'get_name',
  reason: 'no start line',
  code: 'ERR_OSSL_PEM_NO_START_LINE'
}
error Command failed with exit code 1.

It works fine locally,
Reproduction
n/a
System Info
System:
    OS: Linux 5.15 Debian GNU/Linux 10 (buster) 10 (buster)
    CPU: (2) x64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz
    Memory: 1.98 GB / 3.82 GB
    Container: Yes
    Shell: 5.0.3 - /bin/bash
  Binaries:
    Node: 16.20.2 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 8.19.4 - /usr/local/bin/npm
  npmPackages:
    @vitejs/plugin-react: ^4.1.0 => 4.1.0
    vite: ^4.4.9 => 4.4.9
    vitest: ^0.34.5 => 0.34.5

Used Package Manager
yarn
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Removing the vite "server" configuration (which included https certificate imports) fixed this.


⚠ ClamAV has degraded performance

In c735d24, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 224 ms

Resolved: ClamAV performance has improved in 48d3cd8.


Audio files filename is not retrieved

When an audio file is sent to the bot, such as an mp3, its name is shown in the conversation as the file is captioned with its name. The bot's message only contains a mime_type and while getFile() can find the correct extension, the file name itself is lost despite it clearly appearing in the conversation.

hello,
telegram api does not send the filename with an audio message currently, there is nothing telepot can do to fix that. however, you will get the title, performer and other id3 tags the mp3 file may have.
if you absolutely need the filename, try contacting @BotSupport.


Ensures there's a consistent way to route to shows in Emission

We had three places with 2 different ways of routing - this consolidates them all and makes sure we have the entity business set up too.
#trivial #skip_new_tests

Fails

:no_entry_sign:

Missing Test Files:

src/lib/Components/Lists/__tests__/SavedShowItemRow-tests.tsx
src/lib/Scenes/Map/Components/__tests__/CitySwitcherButton-tests.tsx

If these files are supposed to not exist, please update your PR body to include "#skip_new_tests".

  Generated by :no_entry_sign: dangerJS

Ah yeah, this also gets LD-301

Nice!


👤 Saving an Integration requires save to be set twice

This is a...

[ ] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ x] Bug report
[ ] Documentation issue or request

@gaughan your comment is about the UX, right?
Because it's been a deliberate decision to have the integration Saved only after the name is picked in the second screen.
This is because we don't have the inline editing of the integration name. I think it's been a deliberate choice, but I need to understand how much this matter to you.

I think what users expect to happen when clicking on the "save" button is a background save.
We do need the name/description screen when users first click "save" in the workflow because we need at least the integration name to save a draft, but the second time around, we can probably perform a background save.
I think part of the reason for not having the inline editing was because of the layout change. I'm not sure if inline edit is something easy to add? And also if we want to re-work the layout at this point to consider giving users a way to inline edit?
How often do users need to change the name and add a description? They can always do it via the integration details page. Maybe we just don't show the name/description page the second time around?
WDYT @riccardo-forina ?

Yes, this is a leftover of the early iteration of the POC, but I think there is still some value on the way it's done. As you said, there is no way to rename an integration inline, and that's for a few reasons:

there is really no space in the already crowded header to add the inline edit widget
even if we manage to find the space to add it back, there would be no way to change the description but exiting the editor and opening the details page
it's not trivial to implement :P

So my reasoning was, why don't we get the user to the save page every time he wants to save? This way it would be possible to change both the name and the description at any time.
But I understand this makes quick saves more cumbersome, so we can restore the original flow if you prefer it that way. So:

for new integrations, clicking on either save or publish will show the form page.
for existing integrations, save and publish will act immediately, with one small gotcha: the content of the page will be replaced with a spinner while the save is in progress because we need to wait for the save result to be sure to work on the right integration object.

Hope this is clear.

My end user expectation from the first screen is that I am done, I click save so I'm done.
We could get around this in the future by automatically naming "Integration1" 2,3, etc
It's not an item we need to prioritize right now tho.

Would renaming the first "Save" button to "Review", just like the last step before confirming a purchase on Amazon, work?

Yea not a bad idea!

Which "save" are we talking about here? If it's the "Save" on "Add to Integration" page, does it mean the next page title would need to be changed to "Review integration"? And by changing it to "Review", would it imply something else to the users? What would they expect to see on a review screen?
I think the Amazon use case is for users to review items in their shopping cart? Or you're talking about AWS?
I'd love to get @TovaCohen 's opinion on changing button labeling as well.

I think that "Review" implies "Please confirm that everything is in place and you are ready proceed and make something happen."
So I do not think that "Review" is a good option.
I think that what Ricardo describes at the end of his most recent comment is the best way to present this to users. He says:
we can restore the original flow if you prefer it that way. So:
for new integrations,

clicking on either save or publish will show the form page.
for existing integrations, save and publish will act immediately, with one small gotcha: the content of the page will be replaced with a spinner while the save is in progress because we need to wait for the save result to be sure to work on the right integration object.

@dongniwang the first page would change to review, the form page would still be "save".
I see where you are coming from @TovaCohen we are naming in the second screen not reviewing the details are correct.
If we stick with two separate pages, for new integrations, this wouldn't solve the double save right?
Having it on one page feels like the right option to me.

My vote goes to restore the original flow.

I agree with Dongni. I think that two Saves the first time, because you have to give the integration a name, is fine.

Do we need this for 7.4? Or we flag it as an enhancement?

Not to put my hands forward, but this is no small change.


[8.x] Add the ability to pass parameters to Seeders call

Currently passing parameters to seeders call requires to go trough hoops and overwriting base methods of the seeders class
Eg: https://stackoverflow.com/questions/32342289/laravel-passing-variables-from-one-seed-file-to-another/32921227#32921227
This PR allows to pass parameters when invoking seeders without being a breaking change
$this->call(UserTableSeeder::class, false, "Param1", "Param2");
$this->callSilent(UserTableSeeder::class, "Param1", "Param2");

class UserTableSeeder extends Seeder {
    public function run($param1 = null, $param2 = null) {
        // Do something according to $params
    }
}

@GrahamCampbell The breaking change to the signature was removed in this PR so if you agree I think it can go to [7.X]

There is still a breaking change, it's just hidden. Please just update the signature as it was before.

@GrahamCampbell Okay done :tired_face:

Thanks. :)


Please help solving my (brain)problem with numpy or Keras.

I have following layout of numpy array:
arr1=[
[1,2,3,4,5,6,7,8,9,10],[2,3,4,5,6,7,8,9,10,11],[3,4,5,6,7,8,9,10,11,12],[4,5,6,7,8,9,10,11,12,13], .... more
[1,2,3,4,5,6,7,8,9,10],[2,3,4,5,6,7,8,9,10,11],[3,4,5,6,7,8,9,10,11,12],[4,5,6,7,8,9,10,11,12,13], .... more
[1,2,3,4,5,6,7,8,9,10],[2,3,4,5,6,7,8,9,10,11],[3,4,5,6,7,8,9,10,11,12],[4,5,6,7,8,9,10,11,12,13], .... more
..... more
]
I spend the whole sunday to achieve this using reshape ittering arround and so on but without success.
For mesuring the consistency of dataset during process it is filled with the timestamp of each datapoint. my target array schould look like:
arr2=[
[1,2,3,4,5,6,7,8,9,10,1,2,3,4,5,6,7,8,9,10,1,2,3,4,5,6,7,8,9,10... more(vertical len of arr1) ],
[2,3,4,5,6,7,8,9,10,11,2,3,4,5,6,7,8,9,10,11,2,3,4,5,6,7,8,9,10,11,..... more(vertical len of arr1)],
[3,4,5,6,7,8,9,10,11,12,3,4,5,6,7,8,9,10,11,12,3,4,5,6,7,8,9,10,11,12],
more( horrizontal len of arr1 )
My attempts are allway result in randomply shuffled values.
The idea is to learn 1,2,3,4,5,6,7,8,9,10 to predict 11
or 2,3,4,5,6,7,8,9,10,11 to predict 12
but i need that to do for 329*10 inputs wich leads to 329 outputs.
Is this the right approach=? Do i have a bigger missunderstanding? is there a way to do it more elegant in Keras=?

https://picload.org/image/rcdlaror/unbenannt.png
here is link with a ecel screenshot for discribing my problem.

Is this a two step process? Firstly you want to flip / mirror your matrix (assuming that is how you represent the list of lists) to give you:
arr1_mirrored=[
[1,2,3,4,5,6,7,8,9,10], [1,2,3,4,5,6,7,8,9,10], [1,2,3,4,5,6,7,8,9,10], [1,2,3,4,5,6,7,8,9,10], [1,2,3,4,5,6,7,8,9,10],  .... more
[2,3,4,5,6,7,8,9,10,11],[2,3,4,5,6,7,8,9,10,11],[2,3,4,5,6,7,8,9,10,11],[2,3,4,5,6,7,8,9,10,11] .... more
[3,4,5,6,7,8,9,10,11,12], [3,4,5,6,7,8,9,10,11,12], [3,4,5,6,7,8,9,10,11,12], [3,4,5,6,7,8,9,10,11,12].... more
..... more
]

And then run a flatten across the numpy arrays to give you a single array for the rows of the matrix?
That would in theory give you your arr2?
Although this does not seem a Keras specific bug or issue and more of a general question perhaps better suited for StackOverflow?


Link to centurylinkcloud.com doesn't work

The link to https://www.centurylinkcloud.com/ doesn't go anywhere. If you drop the https it redirects to https://www.ctl.io/

Thanks. This is fixed as of https://github.com/CenturyLinkLabs/imagelayers-graph/pull/87


Pin version of skopeo

Ran into issues with latest and the others are pinned
Description
Pin the version of skopeo
Why is this needed
I ran into issues with the latest skopeo. Pinning it avoided it, and the others seem to be pinned (at least registry and bash), so let's pin this too.
Fixes: #
How Has This Been Tested?
Yep, tested in a VM
How are existing users impacted? What migration steps/scripts do we need?
Should avoid a potential issue
Checklist:
I have:

[N/A] updated the documentation and/or roadmap (if required)
[N/A] added unit or e2e tests
[N/A] provided instructions on how to upgrade

@swills what kind of issues did you have?

@swills what kind of issues did you have?

I believe it was with certs, but I'm not sure. I can't seem to reproduce it now, so maybe it was something else and I was mistaken. v1.5.1 seems to work OK for me now.


Just sent you a matrix message.


React app calendar improve display

Description
Adapt display for events page.
Still problems with calendar but it wil be fix in a later pull request
Tests

Steps to reproduce :

Go to events page

Expected results :

It's better

Screenshots

Some code smells, but it's because some actions are stillto be fix in calendar ChooseWeek component (fix in next pull request)


Add chunk Tensor Method

Feature description
Add a chunk method on tensor to faciliate splitting a tensor into a given number of chunks
Feature motivation
Its a fairly common operation supported by other ML frameworks.

I would like to work on this issue, can you assign it to me?

Nice! Let me know if you need any guidance. You can also find me in the Discord as @dcvz.

I would like to work on this issue, can you assign it to me?

Done

I just had a brief look at the source code, the file I should modify is src/tensor/api/base.rs right, and the interface is as follows:
pub fn chunk<const D2: usize>(Tensor<B, D2, K>& tensor , chunks: usize, dim: usize = 0) -> Vec<Tensor<B, D2, K>>
{
}

I just had a brief look at the source code, the file I should modify is src/tensor/api/base.rs right? And the interface is as follows:

Correct! I think interface can likely be the following, if you do the chunking in base space:
pub fn chunk(self, chunks: usize, dim: usize) -> Vec<Self>

Although given that some of the backends already have their own implementations, it might be better to do this backend specific instead of general (depends on what optimizations they have). What do you say @nathanielsimard ?

I think leveraging the implementation of the backend is a good idea!

@dcvz can this issue be closed as the main PR is merged?

I'm working on the backend implementation, we can use this issue or open another issue as a tracker.


net: EPROTOTYPE surfaced from write() on macOS due to kernel bug

What version of Go are you using (go version)?

$ go version
go version go1.17.6 darwin/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tmm1/Library/Caches/go-build"
GOENV="/Users/tmm1/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/tmm1/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/tmm1/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.17.6/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.17.6/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.17.6"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/tmm1/fancybits/channels-server/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_2/hljyy_zj3912lv9qqpy70t5w0000gn/T/go-build1772962119=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I have a http server running on macOS, which uses io.Copy() to stream data out to the http response writer.
What did you expect to see?
When the client closes the socket, I expect to see ECONNRESET or EPIPE
What did you see instead?
I sometimes see EPROTOTYPE instead:

2022/03/04 06:37:26.032031 write tcp <IP_ADDRESS>:8089-><IP_ADDRESS>:53525: write: protocol wrong type for socket

2022/03/05 10:25:59.675548 write tcp <IP_ADDRESS>:8089-><IP_ADDRESS>:49209: write: protocol wrong type for socket

2022/02/28 07:01:09.358647 write tcp <IP_ADDRESS>:8089-><IP_ADDRESS>:50689: write: protocol wrong type for socket

This appears to be due to a well-documented macOS kernel bug: http://erickt.github.io/blog/2014/11/19/adventures-in-debugging-a-potential-osx-kernel-bug/
Many other runtimes have experienced this issue, and the suggested workaround is to retry the write operation.
See https://bugs.python.org/issue44229 and similar links on https://github.com/tokio-rs/mio/issues/1364 (for workarounds in libuv, dotnet, gevent)

cc @neild

Do you have a way that we can reliably reproduce the problem?  Even if we have to run the test many times?  That would help a great deal in knowing whether we have fixed it.  Thanks.

I have observed this logged on customer installations and don't have a repro myself yet.
This particular customer is running on macOS 10.13.6

Rolling forward to 1.20.  Please comment if you disagree.  Thanks.


R119 cb

fixes and improvements

Refer to this link for build results (access rights to CI server needed):
/job/libnd4j_PR/27/

Refer to this link for build results (access rights to CI server needed):
/job/libnd4j_PR/28/


Merging ReSharper and xunit settings

Specifically, AppDomain and shadow copy. Both ReSharper and xunit have settings for these, but how should they be merged?
I can tell when xunit's values are specified or not, so can easily tell when ReSharper should provide the value, but don't know what to do when both are specified.
Currently, ReSharper takes precedence.
Reasons for:

You're using ReSharper's runner - you want to configure it, you know where to go.

Against:

The ReSharper runner should behave the same as any other runner - if the external config files are there, they should be used to get the same behaviour (although the converse isn't true - another runner wouldn't behave the same as the ReSharper runner as it doesn't have access to the ReSharper config)

I'd prefer to have 2 levels:

Default: xUnit runner settings is used. This will allow consistent results of the tests as it's executed exactly like how it's done when running on CI server. The usefulness of unit tests are best when using with CI server, majority of which are executed using xUnit console runner.
Override: add the ability in Resharper options to allow xUnit plugin to override settings set in runner configurations with those in ReSharper unit test settings in case developer really need to.


Add null case to getSampleValueByType

The example for a schema with "type": "null" is rendered as "?". That should be null.

Thanks for your PR !!!


Added created date field to image entity

Hey,
I've added created date field to image entity.

Looks ok to me!

Hey @jakubsacha, thanks for your contribution, and sorry for the delay! Can you rebase this on master before I merge it?


Branch v1.3b refine commands

This PR tackles two portions: features and bug fixes.
Features
Add/Delete/Mark Assignment Command change

Change add, delete and mark assignment to refer to index.
delete and mark assignment has been greatly simplified to be COMMAND INDEX, where index is the currently displayed assignment list
Since delete and mark assignment references the active person, accessor methods have been created for these commands to check the presence and get the activePerson.
All test case has been updated to meet the new add, delete, mark assignment changes

fixes #109
Removal of Late status

Late Status has been removed and all occurence of it within test cases and main program have been removed due to time sensitive test case.
SampleDataUtil has been manually updated to change those with default LATE status to Completed status

fixes #60
Documentation
User guide and developer guide have been changed to reflect the changes in assignment commands.
Optimisations

updateFilteredAssignmentList will no longer create a new filtered list every time the assignments change. This is because all fields in models are final, and so assignment list will be using the same UniqueAssignmentList but contents are cleared then updated with the new active person's list.
Active Person is changed to Optional since there can be an absence of Active person, ie. no person's assignment list selected.

Bug Fixes
Previously give 1 d/some task by/18/01/2019, 1800 will give an error because there is a whitespace between date and time. This is unnecessarily restrictive.

Changes are that whitespaces between comma and date, comma and time will be ignored.

fixes #117

Codecov Report

Merging #118 (a0f021c) into master (276825b) will increase coverage by 0.27%.
The diff coverage is 82.14%.

@@             Coverage Diff              @@
##             master     #118      +/-   ##
============================================
+ Coverage     74.71%   74.98%   +0.27%
  Complexity      598      598
============================================
  Files            89       89
  Lines          1811     1783      -28
  Branches        202      198       -4
============================================
- Hits           1353     1337      -16
+ Misses          403      392      -11
+ Partials         55       54       -1

Impacted Files
Coverage Δ

...main/java/seedu/address/commons/core/Messages.java
0.00% <ø> (ø)

...ss/logic/parser/DeleteAssignmentCommandParser.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/model/Model.java
100.00% <ø> (ø)

...in/java/seedu/address/model/assignment/Status.java
97.05% <ø> (-0.17%)
:arrow_down:

.../java/seedu/address/model/util/SampleDataUtil.java
25.00% <0.00%> (ø)

...u/address/logic/commands/AddAssignmentCommand.java
88.88% <77.77%> (-2.03%)
:arrow_down:

.../address/logic/commands/MarkAssignmentCommand.java
87.50% <80.00%> (-3.41%)
:arrow_down:

src/main/java/seedu/address/model/AddressBook.java
90.38% <80.00%> (+2.88%)
:arrow_up:

...ddress/logic/commands/DeleteAssignmentCommand.java
100.00% <100.00%> (ø)

...dress/logic/parser/AddAssignmentCommandParser.java
100.00% <100.00%> (ø)

... and 5 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 276825b...a0f021c. Read the comment docs.


building with gulp and automatically picking smallest file

This PR build automatically the .js and .js.gz file and keeps the smallest build for each of those files.
Actuall results:
dotdom-babili.js 781
dotdom-uglify.js 783
dotdom-uglify.js.gz 499
dotdom-babili.js.gz 508
So the gulp task will pick the babili file for js, but the uglify file for js.gz.

Love it! Thanks for the great work @PascalPflaum 👍


Incorrect usage of the verb "teilen" in the German language version of CWA

Describe the bug
The verb "teilen" in German is not necessarily a correct translation of the English verb "to share". In order to convey the meaning of sharing German uses " (etwas) mit jmdm. teilen", " (etwas) untereinander/miteinander teilen" oder "sich (etwas") teilen". Unless the appropriate context has already been established by a previous sentence or reference the verb "teilen" with no further attributes is not an appropriate translation for the English "to share", regardless whether such improper usage is widely seen in machine translations and other mediocre translations. (and yes, there are some exceptions such as "sein Wissen teilen").
"Teilen" when used on its own or with a direct object only typically carries the meaning of "to partition", "to divide", "to split" (cf. the noun "der/das Teil").
Thus the sentence "Teilen Sie Ihre Zufallscodes, damit andere gewarnt werden können." to anyone with a proper understanding of German (and no affinity to and knowledge of the technical concept of CWA or similar apps) should raise the clueless question "Durch was soll ich die Codes denn teilen?"/"What should I divide the codes by?"
To make the story short: please use proper language that adequately expresses the intended message instead of garbled word-by-word translations.
There are probably further instances where the verb "teilen" is incorrectly used to express the meaning of "to share". For the sake of a quality product (geared vastly towards a German-speaking audience) please make sure to use quality language.
Expected behaviour
Proper wording
Steps to reproduce the issue
read the text (without thinking along the lines of the English expression)
Possible Fix
A correct literal translation would be "Teilen Sie Ihre Zufallscodes mit anderen", although this is rather lengthy and in that situation probably not the best of message. The message you want to convey to the user in that situation has the option to share, i.e. to upload their keys. So a possible wording in German could be "Veröffentlichen/publizieren Sie Ihre Zufallscodes" (correct description of the essence of the process, but probably sounds quite formal) or, if you want to be more technical, "Laden Sie Ihre Zufallscodes hoch".
In my opinion the best, most natural and most appropriate expression in that situation is "Stellen Sie Ihre Zufallscodes zur Verfügung" because it properly conveys the message of "donating" (or "sharing") one's codes (to the public), which is what the decision is about in that situation.
Unfortunately I would assume that there are further instances within CWA's German text where the verb "teilen" is used as an improper direct translation of "to share". I cannot judge to what extent further languages suffer from the same issue.
Additional context
The same issue of course applies to IOS as well, so you might prefer to consolidate them.

https://github.com/corona-warn-app/cwa-app-android/blob/2d02523cf429b7329ddb3fd265d4dee6bc4b0607/Corona-Warn-App/src/main/res/values-de/strings.xml#L982

Internal Tracking ID: EXPOSUREAPP-2004

Hello @geos-github,
thanks for sharing your thoughts. After an internal discussion, I will go forward and close this issue. With that decision, we also rely on the comment of @vaubaehn.
Thanks,
LMM
Corona-Warn-App Open Source Team


Andrew Huffman - PR changes

Some changes I made a few months back, as we discussed today.

Awesome, thank you for submitting this! I noticed a few things that should be changed. I'll address those each with a comment.

Thanks for the quick responses! Merging now.


need help on editing nested-forms

Hello,
My aim is to be able to call existing nested objects in my database and edit them.
To do so I created a template which display the form objects according to an xml schema, each class has it's own form.
Example of form :
builder = Nokogiri::XML::Builder.new do |t|
t.agent{
          t.association(:type=>'association', :name=>'orgunits',  :display=>'public', :class_name=>'Orgunit')
          t.association(:type=>'association', :name=>'persons',  :display=>'public', :class_name=>'Person')
          t.rec_class(:type=>'hidden', :value=>'Agent')
          t.rec_id(:type=>'hidden', :value=>'', :display=>'public')

       }

I can display existing objects with the link_to_add like this :
- link = link_to_add_association(' ', f, node_name.to_sym, :partial=>'/studies/display_fields',
                  :render_options => {:locals => {:fedora_object=>data, :rec_type=>node_name, :edit=>true,:xml=>Object.const_get(class_name.capitalize).xml_form.to_xml,  :xpath=>'/'+class_name.to_s.singularize.downcase+'/*'}, },:data => {"association-insertion-method" => "before" },)
                  - link = Nokogiri::HTML(link)

However  when I open my edit popup the link_to add buttons generate wrong names.
It should output :
study[authors_attributes][1395055572220][orgunits_attributes][1395055573891][name]
But it displays :
study[new_authors][orgunits_attributes][1395055573891][name]
Could you help me, I don't think you have time to explore my code but do you know a good way to edit nested forms ?
My github is here : https://github.com/Ezekiah/hydra-head-archipolis/blob/master/app/views/studies/_display_fields.html.haml

Closed due to inactivity.


DotNet Upgrade Assistant installation error

Problem encountered on https://dotnet.microsoft.com/en-us/platform/upgrade-assistant/tutorial/install-upgrade-assistant
Operating System: windows
Provide details about the problem you're experiencing. Include your operating system version, exact error message, code sample, and anything else that is relevant.
C:\Users\whitney\AppData\Local\Temp\24lyese0.5wn\restore.csproj(5,31): error MSB4236: The SDK 'Microsoft.NET.Sdk' speci
fied could not be found.
The tool package could not be restored.
Tool 'upgrade-assistant' failed to install. This failure may have been caused by:

You are attempting to install a preview release and did not use the --version option to specify the version.
A package by this name was found, but it was not a .NET tool.
The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
You mistyped the name of the tool.

For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool

I fixed this problem by adding MSBuildSDKsPath to my path variables


FEATURE REQUEST: Method of monitoring completeness of WALs

We use nagios to monitor our infrastructure.  We have deployed https://github.com/APSL/postgresql-wal-e-nagios to confirm that we have current backups but we would also like to know if WALs are late or there are any missing in the sequence.  check-barman checks that the most recent WAL file is new enough and then checks for the presence of all WAL segments between the last backup and this most recent WAL file.  I started working on adapting this logic to GCS (where we point WAL-E for storage) but it is non trivial logic.  It seems like we could leverage the logic that currently supports wal deletion to do this.  I'm willing to do this work (and test it in GCS) but I would like in the end to contribute that work back to this project.  Do you have any pointers to offer someone in my position?

So, interestingly, I thought Near The Beginning Years Ago that this feature would be necessary for WAL-E, since then I have encountered WAL-gaps literally zero times, in which time WAL-E has archived easily a number of petabytes.
That said, I think it is still a good idea to have a feature to work with listing WAL. It would be quite useful to locate the last WAL segment, for example.
So, my pointer is: I might choose to get a bit more bang out of my implementation buck by writing such a feature with an eye towards size statistics rather than being fixated on checking for gaps.
I welcome your changes. Consider writing a prototype first.

@fdr, Thank you for your feedback.  When you suggest writing a prototype first what do you mean?

Basically submit something that touches the features you want but don't dwell too much on testing or naming things or refactoring. I would estimate such a prototype might take 25% of the time of the entire project.

I've an interest in this from the prometheus perspective. Not sure how would that fit with nagios.
I was thinking that the easiest way would be to signal completion of a wal segment to something else, maybe by using some notifier or even just dumping progress to a file that can be picked by a node exporter.
That would mean having the ability to register this notifier or just writing to a file on each wal archive group completion.
Would something like this make sense? @fdr

There are a couple of ways to do this, probably more roundabout than you'd like but also compatible with more archivers.
One is to monitor the postgres archive_status directory, e.g. with inotify. It has a simple naming scheme around "$NAME.ready" and "$NAME.done" segments.
That's a bit roundabout, but would it work?

@pcarranza If there are Prometheus metrics output, it can be easy enough to grab the current stat with whatever tool language and create a Nagios check from that.


Improve Logging

Hello,
This PR improves the actual logging of the bootloader.
Tasks:

[x] Separate the logger from the framebuffer
[x] Add support for Serial Being logger
[x] Add configurations for enabling or disabling these methods of logging

Closes #306
Thanks!

Makes sense. I'll also block config.txt on this as well, once the kernel config is in place.
It may yet again be wise to wait on #302 to avoid conflicts before doing the kernel config. So, perhaps do what is currently in this PR separately, as it'll be a huge help.

I can't apply the changes proposed by @jasoncouture in the linked issue because it's very difficult to refactor BIOS stages due incompatibility problems of the used crates of the logger. So, I think that this PR is ready to merge.

Thanks!


inactive regions?

can someone suggest how to make this all work for inactive regions (e.g. proprocessor inactive chunks)? I think it would rely on clangd features in https://reviews.llvm.org/D67536. Will these get mapped to a specific hl group by this plugin, or is something else required? Thanks.

You can use hlgroup LspComment to give those regions a highlight. Semantic tokens has now been merged into master. Neovim nightly will now do it automatically with highlight @comment

At least, this worked for inactive ifdefs. If they use a separate token or modifier you can use the table highlighter.


Too hard and ugly to obtain interval boundaries

If you want the extrema, you can use interval.extrema, but that returns another interval. I can see why, but it's counter-intuitive in some cases.
Furthermore, interval.components returns instances of interval, instead of interval.Component as I would expect.
I see no readable way to get the superior and inferior boundaries of an interval, so I've been using min(interval)[0] and max(interval)[0], which is a little ugly, but it appears to work.
Am I missing something? If it's something you agree with, I could try and patch it. I just wanted to discuss it first.

There are two ways of iterating over the components of an interval.
You can iterate on the connected components of an interval:
>>> [x for x in interval([1, 2], 3)]
[(1.0, 2.0), (3.0, 3.0)]

Each component behaves like a named tuple:
>>> x = interval([1, 2], 3)
>>> x[0].inf
1.0
>>> x[1].sup
3.0

You can use the components attribute to iterate over the components so that each component is itself an interval:
>>> [x for x in interval([1, 2], 3).components]
[interval([1.0, 2.0]), interval([3.0])]

I updated the documentation to explain this difference.  I hope it is clear now.

Okay, I understand. Thank you for your work, it's been useful to me :)