Add return types and override modifiers

This makes things a little bit more consistent; For now I only did it for algebird-core

How did you do this BTW? Was this a scalafix?

can we do this without making mima unhappy?

I tried to use scalafix ... but it didn't work out well enough. There's a rule for it, but is a bit buggy; I took the easy way out and used IntelliJ for a bit 😄
RE: MiMa ... yeah it should be possible

Codecov Report

Merging #717 into develop will decrease coverage by 0.04%.
The diff coverage is 79.53%.

@@             Coverage Diff             @@
##           develop     #717      +/-   ##
===========================================
- Coverage    89.67%   89.62%   -0.05%
===========================================
  Files          112      112
  Lines         8938     8938
  Branches       325      325
===========================================
- Hits          8015     8011       -4
- Misses         923      927       +4

Impacted Files
Coverage Δ

.../main/scala/com/twitter/algebird/VectorSpace.scala
75% <ø> (ø)
:arrow_up:

...rc/main/scala/com/twitter/algebird/SGDMonoid.scala
53.33% <ø> (ø)
:arrow_up:

.../main/scala/com/twitter/algebird/RightFolded.scala
100% <ø> (ø)
:arrow_up:

...ain/scala/com/twitter/algebird/DecayedVector.scala
76.47% <ø> (ø)
:arrow_up:

.../src/main/scala/com/twitter/algebird/MinPlus.scala
100% <ø> (ø)
:arrow_up:

.../src/main/scala/com/twitter/algebird/Functor.scala
0% <ø> (ø)
:arrow_up:

...a/com/twitter/algebird/statistics/Statistics.scala
70.83% <ø> (ø)
:arrow_up:

...main/scala/com/twitter/algebird/HashingTrick.scala
0% <0%> (ø)
:arrow_up:

...cala/com/twitter/algebird/matrix/DenseMatrix.scala
0% <0%> (ø)
:arrow_up:

...in/scala/com/twitter/algebird/StatefulSummer.scala
0% <0%> (ø)
:arrow_up:

... and 66 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 0f3b440...5f8bc85. Read the comment docs.


Fix race condition in resource_action_consistency_check

Description
Fix race condition in the resource_action_consistency_check method. The assertion would fail when more resource actions are added in between the execution of both SELECT queries. This PR ensures that both queries are executed in a transaction with the repeatable_read isolation level to prevent this race condition.
Self Check:

[ ] Attached issue to pull request
[x] Changelog entry
[x] Type annotations are present
[x] Code is clear and sufficiently documented
[x] No (preventable) type errors (check using make mypy or make mypy-diff)
[x] Sufficient test cases (reproduces the bug/tests the requested feature)
[x] Correct, in line with design
[ ] End user documentation is included or an issue is created for end-user documentation

Failed to merge changes into iso5 due to merge conflict. Please open a pull request for these branches separately by cherry-picking the commit that was made on the branch master (git cherry-pick 231a62ac099b788159707561d0a8d93d851b860b).

Merged into branches iso6, master in 231a62ac099b788159707561d0a8d93d851b860b

Not closing this pull request due to previously commented issues for some of the destination branches. Please open a separate pull request for those branches by cherry-picking the relevant commit. You can safely close this pull request and delete the source branch.

This branch was not deleted as it seems to still be in use.


Implement AuthenticateUserTicket

I started implementing ISteamUserAuth/AuthenticateUserTicket. Haven't had a chance to test it, though.

Seems like writing tests for this could be hard, as it requires a valid ticket...

I added a really crude test (takes ticket from env var, uses Audiosurf's AppID to test since that is the easiest one to get a ticket for in my case) and verified my implementation of ticket auth works.

No


[Flaky Test] TestName

Failures Since Open:
Last Failure Date:
Last Failure Link:
Last Failure Message:

Failure Date:
Failure Link:
Failure Message:


Add option to install the role via ansible-galaxy.

Addresses feedback in b/193553018.
Tested:
$ ansible-galaxy install git+https://github.com/GoogleCloudPlatform/google-cloud-ops-agents-ansible.git
Starting galaxy role install process
- extracting google-cloud-ops-agents-ansible to /usr/local/google/home/lingshi/.ansible/roles/google-cloud-ops-agents-ansible
- google-cloud-ops-agents-ansible was installed successfully

The failed Kokoro job is a separate known issue that's being worked on. This doc change is not related to that. Thus merging.


Colored folders and .swig files

This PR has two changes:

Folders appear with medium yellow icons
Swig files appear with green HTML5 icons

IMO the yellow directory icon sticks out a bit too much. I'm happy to merge the .swig support though.

Merged with d8ef8572


UI display date as 12 Dec 2016 or 12/12/2016?

Cant test on the actual UI as the UI on team master doesnt have the updated ui version.

The Development Workflow doc shows you how you can checkout PRs on your computer. (Look for "Test the PR on your computer")
But anyway, it's something like 2016-10-10T4:00 right now.

Yeah, I'll merge #37 into master soonish. Just waiting to see if @nightism will pop up with a PR to implement deadlines.

But anyway, it's something like 2016-10-10T4:00 right now.

I think you can just come up with your own display format. We will likely be changing it very soon to be more user friendly after v0.2 anyway. #37 focuses more on getting the data structures right first, rather than the user interface design.

oh ok thanks!


Feature/methodology buttons

This PR solves three distinct issues:

Show little countries as circles in the map

Show Europe as EU28 in the map

Update paths JSON.
Little hack for reordering paths when we hover over EU28 on the list so we can see the shape highlighted.

Add methodology info buttons

Add new info buttons and update the slugs for the modal metadata.

Extra: Fix layout (the margins were bigger than in the designs)

I think there's a mismatch in the info window of the NDC Content Overview. Looks like it's displaying the NDC Quantifications.
@juancarlosalonso can you check the small islands states pages maybe? When you can zoom in the circles feel a bit weird :/

What I mean by it:

Now we show the circles only at low levels of zoom


Added PSR6 storage

The PSR6 for cache implementation was release a couple of weeks ago. This PR adds a storage for a PSR6 implementation.

@Nyholm 👍 Merged! I'm in Singapore now, will tag when I'm back in Amsterdam (with a working laptop)

Awesome. Thank you!

@frankdejonge any chance of tagging?

@Nyholm @eXtreme tagged 1.0.3 :+1:

@frankdejonge :clap:


Fix 'Heroic throws NullPointerException if it cannot find ElasticSearch index'

will push changes to remote branch and create new request


versions:use-releases does not use repos from parent pom.

I have a parent pom which defines our release repos. This is ignored when using the goal versions:use-releases. The intended behavior is that this will check all repos defined in the "effective-pom" for releases.

Could this be why I cannot set a SNAPSHOT version back to the existing release using this plugin?

The plugin checks all repos if I remove the releases and snapshot tags from the repository definitions. Otherwise, it just checks the snapshots. (which feels backwards to me).

First I need to say defining repositories in a pom file is a bad idea...better use the settings.xml for this...and furthermore the repositories should be defined in the repository manager...Apart from that versions-maven-plugin can not see a difference from which repository an artifact whatever is solved from ....
Another thing is the use-releases goal is intended to resolve the releases.
From the goal docs:
Replaces any -SNAPSHOT versions with the corresponding release version (if it has been released).

Right. If I have two repositories such as this:
        <repository>
            <id>my-release</id>
            <name>My release repository</name>
            <url>http://repo.foo.corp/release/repo</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
        <repository>
            <id>my-snapshot</id>
            <name>My snapshot repository</name>
            <url>http://repo.foo.corp/snapshot/repo</url>
            <releases>
                <enabled>false</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </repository>

Then it will only search the snapshot and not the release repo for releases. That is to say that it will not update any of the versions in the pom. (At least at the time of when I filed the issue in 2016 - I haven't checked if this was ever fixed).
Regardless of whether defining the repositories in the pom is a good idea or not, the behavior of the plugin is incorrect.
I will be releasing some  code this week. I will test this out and see if it's still misbehaving.


Today date text goes white when opening a new UIViewController

[x] I have verified there are no duplicate active or recent bugs, questions, or requests
[x] I have verified that I am using the latest version of CVCalendar.
[x] I have given my issue a non-generic title.

This is how I open the new UIViewController:
@objc func buttonAction(sender: UIButton!) { // When pressing confiureAddWorkoutButton
        let myVC =  self.storyboard?.instantiateViewController(withIdentifier: "LogWorkoutVC") as! LogWorkoutVC
        self.present(myVC, animated: true, completion: nil)
    }

Issue:
Below is a GIF of how it looks. When I open the app, all the dates are black color. But when I press a button and open up a new UIViewController, and close it, the today date becomes white. And when I press another date, and back to today date, it goes to normal(black).

Your Environment

Device used i.e. iPhone 6S: iPhone Pro Max 11
Physical device (y/n): Yes

Managed to fix this by myself. After deleting all the UISceneDelegate related stuff, and only uses AppDelegate - it works fine.


[FLINK-3560] [examples] Remove unchecked output of usage statement in examples

This PR effectively removes all unconditioned outputs of the usage message of the examples.

That is a good point @vasia. Will add the missing ProgramDescriptions.

Added the missing ProgramDescriptions.

I remember a discussion from a while back that we actually wanted to drop ProgramDescription.
It comes from the days when programs had to implement  specific interface and it does not really go together very well with the idea of a simple static main-method as the entry point.

I think Stephan has a point and we should maybe not encourage usage of ProgramDescription in the examples, because we advertise the simple main-method entry point in all the docs.
Other than that, I think it's a good idea to remove the unconditional usage printing.

ProgramDescription has not been marked as deprecated so far. Furthermore it can be used to show information about the program using bin/flink info and is not mandatory.
Admittedly, this feature isn't used by many programs but I think it does not hurt to keep and implement this interface, unless we plan to remove it soon. There was a discussion which also involved ProgramDescription. However, it does not look to me as if it converged to some real action points.

I don't think the examples should implement the ProgramDescription interface. This might give the impression that implementing this interface is mandatory while it is a very optional thing.
I think it is not a problem that optional program parameters such as max-iterations won't be printed anymore. I would expect users to look at the code anyways to understand what is happening and there they will see the optional parameters.

Hmm but if it is nowhere implemented then we could directly remove ProgramDescription. I mean why keeping code in the base which is not used?
Furthermore, I don't think that it would harm if people implemented this interface. And if they look in the code, then they will also see that it's highly optional.

From my side, +1 for removing the ProgramDescription interface.
I think it is a mismatch with the main() method based approach, because it needs to instantiate the class, while the general entry point is static. That does not go well together in my opinion. People will write programs with no default constructor. Previously, with the Program interface, such a constructor was also mandatory, it did fit better there.

That is a good point with the instantiation of the instances. I will update the PR accordingly.

Removed the ProgramDescription interface and rebase the PR on the latest master.

Thanks, Till! I think this is ready to finally be merged. I will go ahead and do it.


Notifications: enable notifications on Event View

This has landed, needs more polish such as https://github.com/hydrogen-sailfishos/sfos-hydrogen/issues/43


Replace local copyright check with pre-commit-hooks verify-copyright

Description
The local copyright.py script is bug-prone. Replace it with a more robust centralized script from pre-commit-hooks.
Issue: https://github.com/rapidsai/build-planning/issues/30
Checklist

[ ] I am familiar with the Contributing Guidelines.
[ ] New or existing tests cover these changes.
[ ] The documentation is up to date with these changes.
[ ] The cmake-format.json is up to date with these changes.
[ ] I have added new files under rapids-cmake/

[ ] I have added include guards (include_guard(GLOBAL))
[ ] I have added the associated docs/ rst file and update the api.rst

/merge


Not able to build properly

Hi, I'm trying to deploy my project and I keep getting this error (and sometimes Import #5):
Uncaught (in promise) LinkError: WebAssembly.instantiate(): Import #6 module="wbg" function="__wbg_setInterval_e227d4d8a9d44d66" error: function import requires a callable

Not sure what's going on here, I'm using timers::future::IntervalStream::new(interval); from  gloo-timers.
Everything is up to date, using trunk v0.19.1.
I also have to build with --no-sri, which seems to be only happening when building in release mode, or else I get the integrity error.
Failed to find a valid digest in the 'integrity' attribute for resource 'xxx' with computed SHA-384 integrity 'EisHsZkQm52iwWBJE3epgWPd9KalTlvoVYDHPJylPS6hI0iz06FZmqqGI+i4xubN'. The resource has been blocked

can you create a reproducer for that?

Just created this quickly https://github.com/715209/trunk-building-errors.

Am I doing something clearly wrong?

I just tried it locally with trunk serve and trunk serve --release. Both seem to work just fine.

That's very strange. I used the cargo binstall trunk version. Could it perhaps be an issue on mac os?

Just tried that too. Also using cargo binstall. Same result, works.

Thanks you for checking, what would you recommend me to do now? 😅

I am not sure, because I wouldn't see why the problem would exist, but I am also not able to reproduce it. I guess need to investigate it further.
For the SRI part, it might be you'd been affected by #765 as well. As that might depend on the generated output and isn't 100% reproducible I guess. It should be fixed with trunk 0.19.2 though.

Looks like updating to 0.19.2 solved all issues! Still have no clue why the wbg module had those errors, but that is resolved as well 👍 .

Thanks for reporting back. I am not sure what exactly happened on your side, as it worked for me. Maybe it was a side of effect of the browser blocking the resource due to the SRI issue. Which definitely was an issue that was solved with 0.19.2.
I'll close this issue for now. We can re-open if necessary.


Show Open AI library can talk to Xef server.

The current frontend code uses a custom request to the xef server.
This PR replaces that custom code for the TS openai library.
Currently failing with:
Access to fetch at 'http://localhost:8081/chat/completions' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

The goal here is to show a client with the openai library can target streaming with the Xef server.

I guess we'll merge this after fixing the CORS biz and open a new Pr just for the streaming portion


'MANIFEST_INVALID' when uploading to Artifactory

Description of the issue: When running jib as part of a maven goal, I get the following:
[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:0.9.2:build (build-docker-image) on project jengel-service: Build image failed: Tried to push image manifest for $OUR_REGISTRY/sre/jengel-test:jib but failed because: manifest invalid (something went wrong) | If this is a bug, please file an issue at https://github.com/GoogleContainerTools/jib/issues/new: 400 Bad Request
[ERROR] {"errors":[{"code":"MANIFEST_INVALID","message":"manifest invalid","detail":{"description":"null"}}]}

When looking at the artifactory logs, it seems like the manifest being uploaded is null:
2018-07-10 19:55:25,650 [http-nio-8081-exec-55] [INFO ] (o.a.e.UploadServiceImpl:360) - Deploy to 'et-docker-local:sre/jengel-test/_uploads/49928209-6f48-451f-8bd3-57a329be6880' Content-Length: unspecified
2018-07-10 19:55:25,748 [http-nio-8081-exec-66] [INFO ] (o.j.r.d.v.r.h.DockerV2LocalRepoHandler:257) - Deploying docker manifest for repo 'sre/jengel-test' and tag 'jib' into repo 'et-docker-local'
2018-07-10 19:55:25,761 [http-nio-8081-exec-66] [ERROR] (o.j.r.d.v.r.h.DockerV2LocalRepoHandler:298) - Error uploading manifest: 'null'

Expected behavior: The image should be uploaded to artifactory :D
Steps to reproduce:

Add an artifactory repo as your <to><image> block
Execute mvn to publish image
Receive error ):

Environment:

Current trying on macOS 10.13.5
mvn 3.5.3
jib 0.9.2
Artifactory 6.0.1

jib-maven-plugin Configuration:
                    <plugin>
                        <groupId>com.google.cloud.tools</groupId>
                        <artifactId>jib-maven-plugin</artifactId>
                        <version>0.9.2</version>
                        <configuration>
                            <from>
                                <image>$OUR_REGISTRY/frolvlad/alpine-oraclejdk8:slim</image>
                            </from>
                            <to>
                                <image> $OUR_REGISTRY/sre/jengel-test:jib</image>
                            </to>
                            <container>
                                <jvmFlags>
                                    ...
                                </jvmFlags>
                                <format>OCI</format>
                            </container>
                        </configuration>
                        <executions>
                            <execution>
                                <id>build-docker-image</id>
                                <goals>
                                    <goal>build</goal>
                                </goals>
                                <phase>package</phase>
                            </execution>
                        </executions>
                    </plugin>

Log output: See description above for relevant logs
Additional Information:
Tried running as well with the -X flag in maven with nothing else extreme helpful. I do actually see part of the image layers in an _uploads folder in artifactory, but no manifest.json like I'd expect from an image. Happy to provide additional information if needed!

Hey @Joeskyyy thanks for the report, we'll take a look and see what's wrong with our Artifactory interactions.

I got the same thing, when I tried to push image pulled from local registry:2 (https://docs.docker.com/registry/deploying/#run-a-local-registry) to Openshift (Red Hat Container Registry).
docker push openshift-redhat-registry/testProject/jib-test-project:1.5.2
The push refers to a repository [openshift-redhat-registry/testProject/jib-test-project]
465ecf4ed5fd: Layer already exists
141f70ae30db: Layer already exists
a9dbec2c58b4: Layer already exists
43e653f84b79: Layer already exists
empty history when trying to create schema1 manifest

When checking with API calls:
JIB-generated image pushed to local registry by JIB:
$ curl -X GET http://localhost:5000/v2/jib-test-project/tags/list
{"name":"jib-test-project","tags":["1.5.2","1.6.0-SNAPSHOT"]}
$ curl -X GET http://localhost:5000/v2/jib-test-project/manifests/1.5.2
{"errors":[{"code":"MANIFEST_INVALID","message":"manifest invalid","detail":{}}]}

Centos -image from Docker hub just pushed to local by Docker (renaming to keep thing clearer):
$ curl -X GET http://localhost:5000/v2/centos-local/tags/list
{"name":"centos-local","tags":["latest"]}
$ curl -X GET http://localhost:5000/v2/centos-local/manifests/latest
{
   "schemaVersion": 1,
   "name": "centos-local",...

Hmm, this might be that there is something in our manifest format that Openshift and Artifactory finds to be invalid. I wish those registries could give more detail as to why rather than just giving back "manifest invalid". We will look more into this and try to fix this as a high priority issue.

empty history when trying to create schema1 manifest

The manifest of the CentOS image, which works fine with OpenShift, seems to be scheme1 (although I could be totally out of place).
$ curl -X GET http://localhost:5000/v2/centos-local/manifests/latest
{
   "schemaVersion": 1,

The OpenShift doc says

For this reason, the registry is configured by default not to store schema2. This ensures that any docker client will be able to pull from the registry any image pushed there regardless of client’s version.

Just a wild guess from the logs above and the following OpenShift doc: I guess we are generating schema2 manifests and the user's OpenShift repository cannot store it? Maybe the repository is trying to convert it to schema1 on the fly?

/cc @gshipley @jbaruch

/cc @mfojtik

@Joeskyyy Can you try creating new local docker registry in Artifactory with V1 api support and try pushing image again. You will see flag as follow when you create new local docker registry in Artifactory.

OpenShift registry can store manifest v2 schema, even not configured by default can easily be enabled: https://docs.openshift.com/container-platform/3.9/install_config/registry/extended_registry_configuration.html#docker-registry-configuration-reference-middleware, and should accept them since 3.6.
Configuration in 1.5 vs Configuration in 3.6
@Hi-Fi  can you verify what version of OpenShift were you testing against?
The reason is very well explained here: https://docs.openshift.com/container-platform/3.9/install_config/registry/extended_registry_configuration.html#middleware-repository-acceptschema2 and it's basically to support docker versions previous to Docker 1.10.
I would think that nowadays there are very few (close to none) users with older versions of docker cli, but it would be good to support both schema1 and schema2 in the plugin, defaulting to schema2 but with the ability to override the value, and obviously a nicer error message explaining to the user what to do in case he get's a response from the registry that schema2 is not supported.

@jorgemoralespou: Openshift we have is:
OpenShift Master: v<IP_ADDRESS>.49
Kubernetes Master: v1.6.1+5115d708d7

cc/ @bparees Can you provide any more insight into what's going on here?

@jorgemoralespou the registry logs might provide more insight.  But the theory that a v2 schema is being pushed and the registry is rejecting it seems plausible (I think the normal docker client managed to recognize that situation and fallback to schema 1).
@legionus and @dmage are the real experts here though.

Hi all, fyi I created a ticket for jfrog Artifactory trying to get more info as to what is causing this issue:
https://www.jfrog.com/jira/browse/RTFACT-17134

Seems that files are uploaded OK to Artifactory, so only Manifest error is preventing containers to be usable from there:

[INFO] Retrieving registry credentials for test_artifactory_server:15000...
[INFO] Getting base image test_artifactory_server:15000/test_project/distroless-java...
[INFO] Building dependencies layer...
[INFO] Building snapshot dependencies layer...
[INFO] Building resources layer...
[INFO] Building classes layer...
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/ over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/distroless-java/manifests/latest over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/distroless-java/manifests/latest
[INFO] The base image requires auth. Trying again for test_artifactory_server:15000/test_project/distroless-java...
[INFO] Retrieving registry credentials for test_artifactory_server:15000...
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/distroless-java/manifests/latest over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/distroless-java/manifests/latest
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:c6214c301930c8b579c746a317b3968520dda6e4850731b3aa26795892e9995f over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:c6214c301930c8b579c746a317b3968520dda6e4850731b3aa26795892e9995f
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:363596415e324a41b3cb785da315800d728221092766287806f50f950b5f5366 over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:363596415e324a41b3cb785da315800d728221092766287806f50f950b5f5366
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:ceea43ecb1e567009daa48f0ff3f987a49c01c4b0e20fded2e7dc13d26f7632e over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:ceea43ecb1e567009daa48f0ff3f987a49c01c4b0e20fded2e7dc13d26f7632e
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/distroless-java/blobs/sha256:be7cce24ab14c13de06435c05c9670afd73aebbb96dfd59c49fce9db826b364f over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/distroless-java/blobs/sha256:be7cce24ab14c13de06435c05c9670afd73aebbb96dfd59c49fce9db826b364f
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/uploads/?mount=sha256:363596415e324a41b3cb785da315800d728221092766287806f50f950b5f5366&from=test_project/distroless-java over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/uploads/?mount=sha256:363596415e324a41b3cb785da315800d728221092766287806f50f950b5f5366&from=test_project/distroless-java
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/uploads/?mount=sha256:c6214c301930c8b579c746a317b3968520dda6e4850731b3aa26795892e9995f&from=test_project/distroless-java over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/uploads/?mount=sha256:c6214c301930c8b579c746a317b3968520dda6e4850731b3aa26795892e9995f&from=test_project/distroless-java
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:fc7b4c7963f54d0db0563d722be2969ca2b2962bb2cd18ea92e1ff50da34b052 over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:fc7b4c7963f54d0db0563d722be2969ca2b2962bb2cd18ea92e1ff50da34b052
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:5ffca8b298d5abfc906ae13e87ec2627d482ae8cb8184ca031accb963243fc6a over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:5ffca8b298d5abfc906ae13e87ec2627d482ae8cb8184ca031accb963243fc6a
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:a1aef001875f598a7051ad8d2abbb89be66a29d13c608d65dba7c1c906c668a9 over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:a1aef001875f598a7051ad8d2abbb89be66a29d13c608d65dba7c1c906c668a9
[INFO] Finalizing...
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:7c46de080f2d1c5fb8c4bfbb3cca885c7570299597673f4d985549f850875828 over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:7c46de080f2d1c5fb8c4bfbb3cca885c7570299597673f4d985549f850875828
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:da61c0efb79b224fe7e9147408d60084d973160716de035dd4aec7ace4b672a3 over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/sha256:da61c0efb79b224fe7e9147408d60084d973160716de035dd4aec7ace4b672a3
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/blobs/uploads/?mount=sha256:da61c0efb79b224fe7e9147408d60084d973160716de035dd4aec7ace4b672a3&from=test_project/distroless-java over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/blobs/uploads/?mount=sha256:da61c0efb79b224fe7e9147408d60084d973160716de035dd4aec7ace4b672a3&from=test_project/distroless-java
[WARNING] Failed to connect to https://test_artifactory_server:15000/v2/test_project/test_application/manifests/latest over HTTPS. Attempting again with HTTP: http://test_artifactory_server:15000/v2/test_project/test_application/manifests/latest
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 14.037 s
[INFO] Finished at: 2018-08-06T09:29:14+02:00
[INFO] Final Memory: 64M/671M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:0.9.8:build (default) on project test_application: Tried to push image manifest for test_artifactory_server:15000/test_project/test_application:latest but failed because: manifest invalid (something went wrong) | If this is a bug, please file an issue at https://github.com/GoogleContainerTools/jib/issues/new: 400 Bad Request
[ERROR] {"errors":[{"code":"MANIFEST_INVALID","message":"manifest invalid","detail":{"description":"Circuit Breaker Threshold Reached, Breaking Operation. see log output for manifest details."}}]}

With Openshift and Artifactory it seems that target/jib-cache/metadata-v2.json -file is almost empty content being:
{"layers":[]}
When doing successful against local registry:2 file has layer information (including files in each layer), but no e.g. schemaVersion, mediaType or config that are present in manifest that's downloaded from Artifactory item.

Made some tcpdumping to see what's different. Results below (haven't yet figured out what is the thing causing the issue). Also not sure if (without clearing up those messages) the put should work twice or long after the other things are uploaded. But at least some differences can be seen from those.
Jib:

PUT /v2/test_project/test_application/manifests/latest HTTP/1.1
Accept:
Accept-Encoding: gzip
Authorization: Bearer.removeValidToken
User-Agent: jib.0.9.9-SNAPSHOT.jib-maven-plugin.Google-HTTP-Java-Client/1.23.0.(gzip)
Transfer-Encoding: chunked
Content-Type: application/vnd.docker.distribution.manifest.v2+json
Host: test_artifactory_server:15000
Connection: Keep-Alive

{
	"schemaVersion":2,
	"mediaType":"application/vnd.docker.distribution.manifest.v2+json",
	"config":
		{
			"mediaType":"application/vnd.docker.container.image.v1+json",
			"digest":"sha256:b2a10b2a921637bbee627553275e6f7a849fa511b2bc125167a00494da6e090e",
			"size":963
		},
	"layers": [
		{
			"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip",
			"digest":"sha256:fc7b4c7963f54d0db0563d722be2969ca2b2962bb2cd18ea92e1ff50da34b052",
			"size":7869666
		},
		{
			"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip",
			"digest":"sha256:5ffca8b298d5abfc906ae13e87ec2627d482ae8cb8184ca031accb963243fc6a",
			"size":643663
		},
		{
			"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip",
			"digest":"sha256:a1aef001875f598a7051ad8d2abbb89be66a29d13c608d65dba7c1c906c668a9",
			"size":38870533
		},
		{
			"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip",
			"digest":"sha256:7c46de080f2d1c5fb8c4bfbb3cca885c7570299597673f4d985549f850875828",
			"size":58172233
		},
		{
			"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip",
			"digest":"sha256:363596415e324a41b3cb785da315800d728221092766287806f50f950b5f5366",
			"size":315660
		},
		{
			"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip",
			"digest":"sha256:f73f9ca393435c6e2f011779ee355e622205ac06d88ab956e480001764b4b1ad",
			"size":3112
		},
		{
			"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip",
			"digest":"sha256:ceea43ecb1e567009daa48f0ff3f987a49c01c4b0e20fded2e7dc13d26f7632e",
			"size":19381
		}
	]
}

HTTP/1.1.400.Bad.Request
Date: Thu,.09.Aug.2018.11:31:17.GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Server: Artifactory/6.0.1
X-Artifactory-Id: artifactory_identifier
Docker-Distribution-Api-Version: registry/2.0

{
	"errors":
	[
		{
			"code":"MANIFEST_INVALID",
			"message":"manifest.invalid",
			"detail":
			{
				"description":"Circuit.Breaker.Threshold.Reached,.Breaking.Operation see.log.output.for.manifest.detail"
			}
		}
	]
}

Docker-client

PUT /v2/test_project/test_application/manifests/latest HTTP/1.1
Host: test_artifactory_server:15000
User-Agent: docker/1.12.6.go/go1.7.4.kernel/3.10.0-514.10.2.el7.x86_64.os/linux.arch/amd64.UpstreamClient(Docker-Client/1.12.6.\(linux\))
Content-Length: 1789
Authorization: Bearer.removeValidToken
Content-Type: application/vnd.docker.distribution.manifest.v2
Accept-Encoding: gzip
Connection: keep-alive

{
	"schemaVersion": 2,
	"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
	"config":
		{
			"mediaType": "application/vnd.docker.container.image.v1+json",
			"size": 3473,
			"digest": "sha256:088d204168a91fa85bae7d7208de148c8733243a56f5f3410cb3435be858e499"
		},
	"layers": [
		{
			"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
			"size": 7869666,
			"digest": "sha256:fc7b4c7963f54d0db0563d722be2969ca2b2962bb2cd18ea92e1ff50da34b052"
		},
		{
			"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
			"size": 643663,
			"digest": "sha256:5ffca8b298d5abfc906ae13e87ec2627d482ae8cb8184ca031accb963243fc6a"
		},
		{
			"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
			"size": 38870533,
			"digest": "sha256:a1aef001875f598a7051ad8d2abbb89be66a29d13c608d65dba7c1c906c668a9"
		},
		{
			"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
			"size": 58191675,
			"digest": "sha256:a1d09f4bd8711a78772117d4adc9f0b420a3773cbfe15846f4c65b88b6255a31"
		},
		{
			"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
			"size": 315927,
			"digest": "sha256:7c4d4cbb2a07735cba5bd8a9c7624ecd5170951ec59ac5b96cb5c10e9b51eaad"
		},
		{
			"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
			"size": 3231,
			"digest": "sha256:747822417e29d78d147ceabef840d1b771a7e0d23378bfe3c81cf98e43d9b7b1"
		},
		{
			"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
			"size": 19333,
			"digest": "sha256:5b04d502d1fa4e4b9e1fd9e56c12c966d7787155d0d3a80194963a81c8a997c1"
		}
	]
}

HTTP/1.1.201.Created
Date: Thu,.09.Aug.2018.11:28:25.GMT
Content-Type: text/plain
Content-Length: 0
Connection: keep-alive
Server: Artifactory/6.0.1
X-Artifactory-Id: artifactory_identifier
Docker-Distribution-Api-Version: registry/2.0
Docker-Content-Digest: sha256:9cbafa2ffc22c459065420626b40c5cc65195886289ce0c8969aa1c99cb9fe09

If only removing "+json" from MANIFEST_MEDIA_TYPE error message is:
{
    "errors": [
        {
            "code": "MANIFEST_INVALID",
            "message": "manifest invalid",
            "detail": {
                "description": "null"
            }
        }
    ]
}

@Hi-Fi as I pointed out earlier, this looks like a bug in Artifactory : https://github.com/GoogleContainerTools/jib/issues/534#issuecomment-407752556

@Hi-Fi but thanks for the tcpdump. It is indeed very interesting to compare what Jib and docker push. They don't seem much different, so I am intrigued.

That's OK, as it's chunked so it doesn't need to have that.

Hmm, sometimes MANIFEST_INVALID may actually mean that the container configuration is invalid rather than the manifest (or more specifically, that there is a mismatch between the container configuration and the manifest). @Hi-Fi if you don't mind, could you possibly tcpdump those requests (for sending container configuration)?

You mean the thing mentioned in 'configuration' element? If so, I actually compared the ones in Artifactory. The Docker version is about 4 times bigger.

@Hi-Fi Yep - I believe it is about 4 times bigger because Docker adds the history field that contains a bunch of metadata about each layer.

@Hi-Fi so one theory we've been speculating for long is that the Artifactory parser is not conformant to the standard and crashes if there is no history field.
@coollog can we just put an empty history? The Artifactory ticket seems stalled, so it'd be interesting to see if it will make Artifactory happy in the next Jib release.

@chanseokoh We can try the solution and test it first, but I'd be hesitant to have it be the default behavior, since it adds an unnecessary extra field and some registries may require the number of items in history to match the number of layers.

Seems that there's also some other differences than history -part. Files that end up to Artifactory are below (for Red Hat registry doesn't show at least as easily those uploads, so haven't check how that sees things. Probably same way).
From JIB:
{
	"created": "2018-08-09T12:51:57.725Z",
	"architecture": "amd64",
	"os": "linux",
	"config": {
		"Env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt"],
		"Entrypoint": ["java", "-Dspring.profiles.active=in-memory", "-cp", "/app/libs/*:/app/resources/:/app/classes/", "org.example.test.application.TestApplication"],
		"Cmd": [],
		"ExposedPorts": {
			"8080/tcp": {}
		}
	},
	"rootfs": {
		"type": "layers",
		"diff_ids": ["sha256:a9872a8d1d8497c269582f6ed3eab8507b258ed1865afa31f46c6f8b3adc88ec", "sha256:6189abe095d53c1c9f2bfc8f50128ee876b9a5d10f9eda1564e5f5357d6ffe61", "sha256:ce50d0a8644296d91457dc2206cd8d13b6253a16b18fc7f353bf5541c882facf", "sha256:b5bef9909a5bc0f2e8b14cdb80de2ac206148643db5714b8e1f3f92d5d17f2ba", "sha256:630535e23e69fc9bc784ade975cbbf078b8d2bd90ee662f6e58d9a2b687552ec", "sha256:1ea6b8dab7190bf60a79464f5f7fbea5c276c3005178009b7d7e317ac0c0a6b0", "sha256:b55ee0e95003a168ca12b7d7a0a8fb05e7fb14fe258156b1d1a85a81012aae08"]
	}
}

From Docker client:
{
	"architecture": "amd64",
	"config": {
		"Hostname": "1f39ec5d9a07",
		"Domainname": "",
		"User": "",
		"AttachStdin": false,
		"AttachStdout": false,
		"AttachStderr": false,
		"ExposedPorts": {
			"8080/tcp": {}
		},
		"Tty": false,
		"OpenStdin": false,
		"StdinOnce": false,
		"Env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt"],
		"Cmd": [],
		"Image": "sha256:bc109b38ecc6c38191f4d9d9e295ca1b52c28cc2c749d6e409b47ddcdd269ad6",
		"Volumes": null,
		"WorkingDir": "",
		"Entrypoint": ["java", "-Dspring.profiles.active=in-memory", "-cp", "/app/resources/:/app/classes/:/app/libs/*", "org.example.test.application.TestApplication"],
		"OnBuild": [],
		"Labels": {}
	},
	"container": "5e1acfe1e58c5727d1f59a4a7414af3afd0058893dac336afa9c6b16e4dbb836",
	"container_config": {
		"Hostname": "1f39ec5d9a07",
		"Domainname": "",
		"User": "",
		"AttachStdin": false,
		"AttachStdout": false,
		"AttachStderr": false,
		"ExposedPorts": {
			"8080/tcp": {}
		},
		"Tty": false,
		"OpenStdin": false,
		"StdinOnce": false,
		"Env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt"],
		"Cmd": ["/bin/sh", "-c", "#(nop) ", "CMD []"],
		"Image": "sha256:bc109b38ecc6c38191f4d9d9e295ca1b52c28cc2c749d6e409b47ddcdd269ad6",
		"Volumes": null,
		"WorkingDir": "",
		"Entrypoint": ["java", "-Dspring.profiles.active=in-memory", "-cp", "/app/resources/:/app/classes/:/app/libs/*", "org.example.test.application.TestApplication"],
		"OnBuild": [],
		"Labels": {}
	},
	"created": "2018-08-09T11:24:34.760605095Z",
	"docker_version": "1.12.6",
	"history": [{
			"created": "1970-01-01T00:00:00Z",
			"author": "Bazel",
			"created_by": "bazel build ..."
		}, {
			"created": "1970-01-01T00:00:00Z",
			"author": "Bazel",
			"created_by": "bazel build ..."
		}, {
			"created": "1970-01-01T00:00:00Z",
			"author": "Bazel",
			"created_by": "bazel build ..."
		}, {
			"created": "2018-08-09T11:24:14.500844147Z",
			"created_by": "/bin/sh -c #(nop) COPY dir:8c790ae2c9c23d8536de33a3d75c9d6972b7bd25e9743f1bb940c4ef1eb53b36 in /app/libs/ "
		}, {
			"created": "2018-08-09T11:24:17.973122753Z",
			"created_by": "/bin/sh -c #(nop) COPY dir:79bf607e2fc210c90e55b00e3f6849ed9e15ea4002cbe6e0050b1bd1ba96875e in /app/libs/ "
		}, {
			"created": "2018-08-09T11:24:21.866933058Z",
			"created_by": "/bin/sh -c #(nop) COPY dir:0535fdf23e0d29ca47b7ec967e624c25a15a0f20ba740bb4474b142e86f83150 in /app/resources/ "
		}, {
			"created": "2018-08-09T11:24:27.643603513Z",
			"created_by": "/bin/sh -c #(nop) COPY dir:be66b8b2c128d8d03036cc1727c2691b23be61a98eed726e1325e71b8c40e119 in /app/classes/ "
		}, {
			"created": "2018-08-09T11:24:29.880712091Z",
			"created_by": "/bin/sh -c #(nop)  EXPOSE 8080/tcp",
			"empty_layer": true
		}, {
			"created": "2018-08-09T11:24:32.1796031Z",
			"created_by": "/bin/sh -c #(nop)  ENTRYPOINT [\"java\" \"-Dspring.profiles.active=in-memory\" \"-cp\" \"/app/resources/:/app/classes/:/app/libs/*\" \"org.example.test.application.TestApplication\"]",
			"empty_layer": true
		}, {
			"created": "2018-08-09T11:24:34.760605095Z",
			"created_by": "/bin/sh -c #(nop)  CMD []",
			"empty_layer": true
		}
	],
	"os": "linux",
	"rootfs": {
		"type": "layers",
		"diff_ids": ["sha256:a9872a8d1d8497c269582f6ed3eab8507b258ed1865afa31f46c6f8b3adc88ec", "sha256:6189abe095d53c1c9f2bfc8f50128ee876b9a5d10f9eda1564e5f5357d6ffe61", "sha256:ce50d0a8644296d91457dc2206cd8d13b6253a16b18fc7f353bf5541c882facf", "sha256:ca6c65486d1b31ca342d09625ea909ff06bf61b876b35509ae9f9694e170d79e", "sha256:5a09a0404d0626eab14c41267836ecb023eb52d2f73241afb858bfde6336d0d1", "sha256:a0939605667deb59f16ab6e84b596231230e1e024117ae9007009f72244bf043", "sha256:c8853f54e4024a6957a9fda55e4ad25893c33c978897ce63d106f333de567f5e"]
	}
}

Noticed also funny thing: From those examples I pasted, the docker client example was not working when I used it directly "as is". When I changed Content-Type to "application/vnd.docker.distribution.manifest.v2+json" (adding "+json") and using chunked transfer encoding, I was able to remake the PUT request. So the Content-Type is not causing the issue, it's just probably showing it some other way (or showing it correctly, as with Content-Length the error is just null).

At least empty histrory didn't worked, same error about circuit breaker threshold.

Thanks for getting this info! The Docker client is adding a bunch of extra fields that are Docker V2.2-specific and not required by OCI format. I'm wondering if Artifactory is expecting one of these fields to be present.

Seems that Jfrog repos docker importer checks only a few things for manifest validity: https://github.com/jfrog/docker2artifactory/blob/c1639b1747a4dbb8f348b31ca72adbc9fecae1c4/tests/util/ArtifactoryUtil.py#L51.

@Hi-Fi  The log from RTFACT-17134 indicates that Artifactory is written in Java.  That code seems to be from a test helper for a migration utility.
2018-07-18 08:09:06,843 [http-nio-8081-exec-200] [INFO ] (o.j.r.d.v.r.h.DockerV2LocalRepoHandler:256) - Deploying docker manifest for repo 'mzagar/jib-helloworld' and tag '1' into repo 'docker-local'
2018-07-18 08:09:06,855 [http-nio-8081-exec-200] [ERROR] (o.j.r.d.m.ManifestSchema2Deserializer:133) - ManifestSchema2Deserializer CIRCUIT BREAKER: 5000 Iterations ware performed breaking operation.
Manifest: {"schemaVersion":2,"mediaType":"application/vnd.docker.distribution.manifest.v2+json","config":{"mediaType":"application/vnd.docker.container.image.v1+json","digest":"sha256:840d5635c8968b0d1bfb2fa6b94eb755b8e973b09310b2bdf14ff39c608d3b73","size":694},"layers":[{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:57752e7f9593cbfb7101af994b136a369ecc8174332866622db32a264f3fbefd","size":7695860},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:ba7c544469e514f1a9a4dec59ab640540d50992b288adbb34a1a63c45bf19a24","size":622796},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:079855b1a2fb11564a2bc8ea9f278bcb2bfa9a7a8edbc22653fd4e2afdf5a0c4","size":38708273},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:553e0277f162b20549b8e83df8dd07bd79bfa17ffa8d65b4b95e7258353fbe69","size":2476712},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:12590341691b549b4c86dbbe4fdccc66b0fa39104048252384ab5af1ed89d773","size":104},{"mediaType":"application/vnd.docker.image.rootfs.diff.tar.gzip","digest":"sha256:b5b5c7d33b898d4a1075ab166afc78607af99380e3b85705480c3940f51148e7","size":829}]}
jsonBytes:{"created":"1970-01-01T00:00:00Z","architecture":"amd64","os":"linux","config":{"Env":[],"Entrypoint":["java","-cp","/app/libs/*:/app/resources/:/app/classes/","example.HelloWorld"],"Cmd":[],"ExposedPorts":{}},"rootfs":{"type":"layers","diff_ids":["sha256:a9872a8d1d8497c269582f6ed3eab8507b258ed1865afa31f46c6f8b3adc88ec","sha256:6189abe095d53c1c9f2bfc8f50128ee876b9a5d10f9eda1564e5f5357d6ffe61","sha256:40930fb97dd9e5c822d4b2f9952679758b5272007754a3e2f624c72fa794a008","sha256:8928a2974aad3b02b2e7408678f5ddf1db8bbb24c3cb26dd4292cfc75f078a0f","sha256:06bdc65f4d36b5538573a682d7d5cfcb62e00fe82ef1c21a4ffe743ae9ffac01","sha256:afda9a7d383fa61a2580879372fdb09dbc397e1e80adbc53b9753c1ddd07a7e5"]}}
2018-07-18 08:09:06,855 [http-nio-8081-exec-200] [ERROR] (o.j.r.d.v.r.h.DockerV2LocalRepoHandler:297) - Error uploading manifest: 'Circuit Breaker Threshold Reached, Breaking Operation. see log output for manifest details.'

@briandealwis: Yes, Artifactory is written in Java, but that docker2artifactory importer is util provided by jFrog, which (I think) should mean that it should check validity correctly before trying to copy containers from some other registry to Artifactory. So point just was, that at least in that copy there's not many fields checked, which could indicate that Artifactory doesn't require anything else.
I could think that from JFrog side it should be quite easy to tell what parsing is tried to be done when that error occurs, but sadly they seem to be quite unresponsive.

@jainishshah17 @jbaruch
I used a method decompiler and walked through Artifactory's ManifestSchema2Deserializer class while attempting to push up an image from Jib.  The problem occurs in ManifestSchema2Deserializer#applyAttributesFromContent().
Basically this code walks through the layers and creates blob infos for each layer.  Although it attempts to support containers with no history (which is allowed by the spec, and which Jib does not produce), it does not increment layerIndex when there is no history.  The code looks something like:
private static ManifestMetadata applyAttributesFromContent(...) {
    ...
    final JsonNode history = config.get("history");
    final JsonNode layers = manifest.get("layers");
    final boolean foreignHasHistory = layers.size() == historyCounter;

    int historyIndex = 0;
    int layersIndex = 0;
    while (historyIndex < historySize || layersIndex < layers.size()) {
        final JsonNode historyLayer = (history == null) ? null : history.get(historyIndex);
        final JsonNode layer = layers.get(layersIndex);
        long size = 0L;
        String digest = null;
        // This condition appears to be problematic:
        //  - Jib images have no history, thus `historyLayer` is always `null`,
        //     and so `notEmptyHistoryLayer(null)` is always `false`
        //  - None of our layers are foreign
        // and so layersIndex is never incremented
        if (notEmptyHistoryLayer(historyLayer) || (!foreignHasHistory && isForeignLayer(layer))) { // !!!
            size = layer.get("size").asLong();
            totalSize += size;
            digest = layer.get("digest").asText();
            ++layersIndex; // XXX never incremented
        }
        // build a BlobInfo from digest, size, and created
        // add the blobInfo to the manifest metadata
        // circuit breaker checks
    }
    // populate remaining more manifest metadata
}

...

private static boolean notEmptyHistoryLayer(final JsonNode historyLayer) {
    return historyLayer != null && historyLayer.get("empty_layer") == null;
}

It seems to me that either the conditional marked with !!! should be expanded to include historyLayer == null?

@briandealwis Let me check with Dev Team

If history is the cause, #875 then hopefully solves also this one.

Confirmed: Adding as many history elements as there's layers make container push to Artifactory. Red Hat Container Registry still throws error with this quick try, so it might still require something else.
But Artifactory works when there's equal number of (non-empty-layer) history elements than layers.
For test I only added static ones to jib-core/src/main/java/com/google/cloud/tools/jib/image/json/ContainerConfigurationTemplate.java:
private final List history = new ArrayList();

  private static class History implements JsonTemplate {
        private String author = "Bazel";
        private String created = "1970-01-01T00:00:00:Z";
        private String created_by = "bazel_build ...";
  }

public void addLayerDiffId(DescriptorDigest diffId) {
    history.add(new History());
    rootfs.diff_ids.add(diffId);
  }

Closing this since it should be fixed by #877 (the fix will be in 0.9.10, which should be coming later today or tomorrow).

Tested with Artifactory 6.0.2, works well. Big Thanks!

Version 0.9.10 has been released!


add tests for regression scenario in error analysis and fix issues in matrix filter

add several tests for 1.) regression scenario 2.) filters and refactors some of the common test code
fix two issues in the matrix filter:

when specifying filters, metric calculation fails due to pred_y/true_y being pandas dataframes
the total counts matrix was incorrect for regression scenario, it was actually showing rounded total error

closing for https://github.com/microsoft/responsible-ai-widgets/pull/603

(forgot I need to create it off of main repo instead of fork for build to pass)


Add SPI support

Currently only I2C is supported by the driver.

This isn't as trivial as initially assumed, so will take longer to implement.


Braintree Payment issue

Hello,
I have used Braintree Payment to place an order, but got an error below

so does it support Braintree Payment?
Thanks

Braintree is not supported out of box. So far, there is no payment integration repositories available either. So you should integrate it yourself from your side.
You can read about payment integration here: https://hyva-themes.github.io/magento2-react-checkout/payment-integration/


Xaero's map chest tracker crashed

Bug description
When I want to play MineCraft,I saw the mod NEC's screen,it told me to send a report
I don't know what happened
Steps to reproduce
Launch Minecraft
Expected behavior
No response
Actual behavior
No response
Relevant logs
crash-2024-06-23_10.09.39-client.txt
Minecraft version
1.20.4
Xaero's Map Chest Tracker Integration version
2.0.1
Chest Tracker version (optional)
2.4.3
Xaero's Map version (optional)
24.2.0
Other information (optional)
No response
Check list

[X] I have verified that the issue persists in the latest version of the mod.
[X] I have searched the existing issues and confirmed that this is not a duplicate.

more information:

Duplicate of #7


How to focus or open specific apps with shortcuts

Focus or Open specific app with shortcut
I recently started to use aerospace (coming from yabai & skhd), and I was struggling to find a way to open / focus specific apps
So I you have such need here my way of doing it, just replace APP_NAME by yours with your custom keybing, and it will be work for most app.
AeroSpace is using the .app name, so it's pretty straightforward, work just fine

⚠ If for some reason your app is not the same as 'list-windows' output, you might want to change this a bit, and not using"APP_NAME" ⚠

I was wondering if there is any easier way of doing it too (optimal way) ?
ctrl-cmd-g = 'exec-and-forget APP_NAME="Arc" && (aerospace focus --window-id "$(aerospace list-windows --all | awk -F"|" "/$APP_NAME/ {print \$1}" | awk "{print \$1}")" || open -n /Applications/$APP_NAME.app)'
ctrl-cmd-i = 'exec-and-forget APP_NAME="Alacritty" && (aerospace focus --window-id "$(aerospace list-windows --all | awk -F"|" "/$APP_NAME/ {print \$1}" | awk "{print \$1}")" || open -n /Applications/$APP_NAME.app)'
ctrl-cmd-s = 'exec-and-forget APP_NAME="Slack" && (aerospace focus --window-id "$(aerospace list-windows --all | awk -F"|" "/$APP_NAME/ {print \$1}" | awk "{print \$1}")" || open -n /Applications/$APP_NAME.app)'
ctrl-cmd-d = 'exec-and-forget APP_NAME="Discord" && (aerospace focus --window-id "$(aerospace list-windows --all | awk -F"|" "/$APP_NAME/ {print \$1}" | awk "{print \$1}")" || open -n /Applications/$APP_NAME.app)'
ctrl-cmd-n = 'exec-and-forget APP_NAME="Notion" && (aerospace focus --window-id "$(aerospace list-windows --all | awk -F"|" "/$APP_NAME/ {print \$1}" | awk "{print \$1}")" || open -n /Applications/$APP_NAME.app)'
ctrl-cmd-l = 'exec-and-forget APP_NAME="Linear" && (aerospace focus --window-id "$(aerospace list-windows --all | awk -F"|" "/$APP_NAME/ {print \$1}" | awk "{print \$1}")" || open -n /Applications/$APP_NAME.app)'
ctrl-cmd-o = 'exec-and-forget APP_NAME="Obsidian" && (aerospace focus --window-id "$(aerospace list-windows --all | awk -F"|" "/$APP_NAME/ {print \$1}" | awk "{print \$1}")" || open -n /Applications/$APP_NAME.app)'

Hope it will help some of you 🙏

@nerap: doesn't open already either open the app (if it's not open) or give focus to it? it does for me...

Sometimes is does for some apps, but not all of them, you will have this popup $APP is already open

You can also have the scenario (iTerm if I'm not wrong), where open will create a new window every time
But I think you can't avoid this behavior with open options

@nerap: ah yeah, sorry, -n is what creates a new window of whatever app. If you remove that, it should either open the app or give focus to it. At least that's how it behaves with every app I've tried.

maybe this can be done without a work-around through the api?
I wonder if this can gain some traction if put as a feature request

related:
https://github.com/nikitabobko/AeroSpace/issues/510#issuecomment-2439585933


[FR DateTimeV2] Regular expression causes node to crash

Describe the bug
One regular expression causes an out of memory when extracting french dates, using windows 7/10.
The behaviour is random, but can be reproduced using it from node VM, Jest or just running from debug using Visual Studio Code.
The regular expression causing the heap error is the attached one.
regexp.txt
To Reproduce
Try to extract date time in node from any kind of utterance (I reproduced using "où sont mes clés").
Expected behavior
Date time correctly extracted.
Sample input/output
N/A
Platform (please complete the following information):

Platform: JavaScript
Environment: npm package, node 10.5.0, windows 7/10 [testing with Jest, executing in VM or debugging with Visual Studio Code]
Version of package: 1.1.3

Closing this as I can't replicate in the current code. NPM packages for v1.2.0 will be out soon.


Translation fixes

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Congrats @sofiabsilva on your first pull request (PR)! 🎉
Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝


Add target for native unit test execution for nrfconnect in build_examples.py

Problem
Too many custom scripts for compiling things
Change overview
Adds the target nrf-native-posix-64-tests that builds and runs zephyr native unit tests for nrfconnect
Updated CI workflow to use the build_examples.py script instead of separate script.
Testing
Ran tests locally
Unit tests will run the same thing

fast track: build system change only, has been up for sufficient time for all timezone review, has a few checkmarks already


isort: 4.2.5 -> 4.3.4

Motivation for this change
Update isort to the most recent version
Related to #35444
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

I think isort is a dependency of the some other packages or apps, and we cannot easy move it out of the python-packages.nix

@couchemar the expression can be moved to pkgs/development/python-modules/isort/default.nix and then then called from python-packages.nix with callPackage.

ok, i will change soon

@dotlambda @FRidh
Expression is in separate file now.

@couchemar I simply disabled the failing tests. Please have a look.
@GrahamcOfBorg build python2.pkgs.isort python3.pkgs.isort

Success on x86_64-linux (full log)
Attempted: python2.pkgs.isort, python3.pkgs.isort
Partial log (click to expand)
test_isort.py .......................................................... [ 50%]
..........................................................               [100%]

=================== 116 passed, 3 deselected in 3.52 seconds ===================
test_isort.py .......................................................... [ 50%]
..........................................................               [100%]

================== 116 passed, 3 deselected in 14.75 seconds ===================
/nix/store/fybh12lswybcgzw6s3qn2xy3kvy8kqz8-python2.7-isort-4.3.4
/nix/store/mxhcazyhh8mnqc22aps0b1zi8a2w6npw-python3.6-isort-4.3.4

Success on aarch64-linux (full log)
Attempted: python2.pkgs.isort, python3.pkgs.isort
Partial log (click to expand)
test_isort.py .......................................................... [ 50%]
..........................................................               [100%]

=================== 116 passed, 3 deselected in 6.13 seconds ===================
test_isort.py .......................................................... [ 50%]
..........................................................               [100%]

================== 116 passed, 3 deselected in 30.71 seconds ===================
/nix/store/jafiyzmjiv43qcaiy5v7scpgyr7jx475-python2.7-isort-4.3.4
/nix/store/izrsh0adnyspy8mg1fz15slypsjrv3sp-python3.6-isort-4.3.4

Is there reasons do not merge this request?

None besides me not noticing your approval.


Can GPT Tell Differences Between Image and Generated SBGN?

After you generate an SBGNML document, if something is missing (i.e., a node) can you feed back the SBGNML plus hand-drawn image and ask if GPT knows these are not the same. If it knows not the same and gives explanation, can GPT use that info to improve the generated SBGNML?
Try in the GPT web interface first, before coding.

What if you send the rendered SBGNML and ask if the hand-drawn is same as the rendered? If no, what in the SBGNML can be done to fix it.

Unfortunately, it doesn't give good answers to this either. I tried with the following images:

It says that there are two GRB2 nodes in the rendered one when compared to the hand-drawn image, so one should be removed from the SBGNML. When I said "But, there are two GRB2 nodes in the hand-drawn image, right?" it confirms and says no changes are needed.
If I mention about the incorrect parts, it confirms but it cannot find them itself.


Error: Multiplexer is destroyed` on the server when libp2p circuit is doing something while the client crashes just after connecting

Version: v18
Platform: Linux - 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux, node -v: v8.9.4
Subsystem: muxer

Type: bug

Severity: high
Description: Error: Multiplexer is destroyed on the server when libp2p floodsub is doing something while the client crashes just after connecting
Steps to reproduce the error:
Run a server
Run a client
Connect the client to the server and dial a protocol
The server should send some data and the client should throw when it receives it.
The server will now crash with Error: Multiplexer is destroyed
(Once again discovered this while writing libp2p-nodetrust - btw, here is the server-log.txt)
Note that this error does not occur 100% of the time.

Edit: Turns out circuit and not floodsub is causing this: at Dialer.canHop (/home/maciej/Projekte/libp2p/libp2p-nodetrust/server/node_modules/libp2p-circuit/src/circuit/dialer.js:81:7)

@dryajov ^^

@mkg20001 It seems to happen when circuit is trying to send the canHop message to the other peer, that happens to be the first thing that circuit will do when another peer just connected, but I don't see much going on besides that from the attached log.
One thing that comes to mind is, are you running on the same machine or are your nodes on different machines, if so, it might be a connection drop. Could you run this with debug='libp2p*' please?

@dryajov This was already run with DEBUG=libp2p*. What I was saying that the server is crashing when the connection gets dropped due to the other peer crashing. I'm reporting this issue because this could easily be abused to crash important nodes maliciously.

Edit: Also note that in the log the error below "this is the actual crash" is server side and not on the client (the client was supposed to crash after receiving the servers response)

Got you, thanks for clarifying.
Does something similar happen when circuit is disabled? I think canHop just happens to be the next thing that happens in the sequence of events? We should definitely handle muxer errors more graciously.

Yes. This time it took 2 runs to crash the server.
server-logs.txt

Ah, this is it -
/home/maciej/Projekte/libp2p/libp2p-nodetrust/server/node_modules/libp2p-mplex/src/internals/index.js:95
      throw new Error('Multiplexer is destroyed')

We're mixing callbacks and throws....

Here is the line - https://github.com/libp2p/js-libp2p-mplex/blob/bfc6b113e0026618cb72899b39d162eddeb42b3f/src/muxer.js#L54
We're never handling the throw anywhere.

I think this should help - https://github.com/libp2p/js-libp2p-mplex/pull/75/files
Note that there are other throws, but they don't seem to be used anywhere. Specifically in -https://github.com/libp2p/js-libp2p-mplex/blob/bfc6b113e0026618cb72899b39d162eddeb42b3f/src/internals/index.js#L106 which gets called by https://github.com/libp2p/js-libp2p-mplex/blob/bfc6b113e0026618cb72899b39d162eddeb42b3f/src/internals/index.js#L136, which doesn't get used anywhere.

Here is the required change in libp2p-switch https://github.com/libp2p/js-libp2p-switch/pull/245

@jacobheun was this handled by your other PRs?

@diasdavid this was ultimately resolved by https://github.com/libp2p/js-libp2p-mplex/pull/79, which catches the error and returns it via the callback. This should be closable. This fix is available in libp2p-mplex 0.8.0.

RAD! :D Thanks for double checking :)


Problem with jsx-closing-bracket-location rule

After enabling
    "react/jsx-closing-bracket-location": [2, {"location": "after-props"}],

rule in project's ESLint config, next element start producing errors,
<Button
    bsStyle="success"
    data-id={showPromoteModal}
    onClick={this.handleUserPromote}>
    Promote
</Button>

But from rule definition I believe that it should only validate self-closing JSX tags.
I'm not sure how better handle this situation, maybe adding some configuration value to the rule, but in total, when rule enabled I only want to validate closing bracket location for self-closing JSX tags, like,
<Route
    name="page"
    handler={Page}
    path="/page/:id" />

and do not validate normal tags, like Button above.
What do you think? Does it make sense for you?

Well, currently the rule enforce the same style for self-closing and non-self-closing tags and do not make any distinction.
What you want is to be able to configure two different style for self-closing and non-self-closing tags, or enforce only one ?

Yep, I want be able to configure two different styles for self-closing and non-self-closing tags.

Ok, it could be a future option for this rule.

+1 for splitting them up.


Problem adding user in Roles.GLOBAL_GROUP

I'm using Meteor 1.8.1 and trying to create a default user on startup with a clean install, using this code:
const createAdmin = () => {
  const adminEmail  =<EMAIL_ADDRESS>  const adminExists = Meteor.users.find({ 'emails.address': adminEmail }).count();

  if ( adminExists === 0 ) {
    const adminDoc  = {
                        email: adminEmail,
                        password: 'password',
                      },
          userId    = Accounts.createUser( adminDoc );

    Roles.addUsersToRoles( userId, 'admin', Roles.GLOBAL_GROUP );

    Meteor.users.update( userId, {
      $set: {
        name: {
          first: 'Admin',
          last: 'User',
        }
      }
    });

    return userId;
  } else {
    return false;
  }
};

The user creation works just fine, but when it gets to the Roles part, I get the following error:
MongoError: Cannot create field '__global_roles__' in element {roles: [ "user" ]}
    at Function.create (/Users/allen/.meteor/packages/npm-mongo/.<IP_ADDRESS>j1pkfe.pd2v++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/mongodb-core/lib/error.js:43:12)
    at toError (/Users/allen/.meteor/packages/npm-mongo/.<IP_ADDRESS>j1pkfe.pd2v++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/mongodb/lib/utils.js:149:22)
    at coll.s.topology.update (/Users/allen/.meteor/packages/npm-mongo/.<IP_ADDRESS>j1pkfe.pd2v++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/mongodb/lib/operations/collection_ops.js:1414:39)
    at /Users/allen/.meteor/packages/npm-mongo/.<IP_ADDRESS>j1pkfe.pd2v++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/mongodb-core/lib/connection/pool.js:532:18
    at _combinedTickCallback (internal/process/next_tick.js:132:7)
    at process._tickDomainCallback (internal/process/next_tick.js:219:9)

Anyone else run into this issue? Any idea why I can't create a __global_roles__ field? I ran this immediately after running meteor reset, so there should not be any existing database to create problems.
Thanks for any advice or feedback you may have!

As is so often the case, nevermind! The application I was updating had a default Accounts.onCreateUser() function that set a user's role to 'user' indiscriminately. This, of course, made it impossible to go back and add group-based roles.


Grading

I just looked at Yash's message in Slack, and I updated my grading issue to reflect it. I created a google form (linked on the issue), to help make sure there isn't confusion.

Fixed due to error in one of the files. (Credit to Avika)


fix(url-sync): Makes url sync more reliable

2 main changes here :

the url-sync internal widget now relies on the helper directly and
not on the instantsearch lifecycle anymore.
there is dedicated channel of update for the changes coming from the
history (private API for the moment)

FIX #730
FIX #729

Other than the two comments I made: LGTM

Tests are passing and all the remarks are taken care of, merging!


[Development] npm install errors on windows.

I seem to be having issues with NPM install on windows.
Hangs for a bit few seconds and then  errors out.
  Thanks in advance.  :)

Hmm, I'm not sure what this could be @keesee. It looks like the Git command to install node-libcurl is failing. What version of Git do you have installed on your Windows machine?.
This seems less related, but you also need to make sure you have the requirements installed to build node-libcurl on Windows? https://github.com/JCMais/node-libcurl/#window

Hey @keesee,
I just spent the last day fixing a Windows-specific bug, and ran into this same problem. I ended up converting all Git npm dependencies to regular dependencies to get around it. If you pull down the latest develop branch it should (hopefully) work for you.

Going to close this one for now, but I will reopen if it still doesn't work for you.


Add index.html to a main branch

Add index.html by merging develop and main branches

Added by merging develop branch.


Detect mutli-line text in one box?

I have re-trained the model based on my own dataset. And it works better than east. But there is a problem. Sometimes the model detect multi-line in one box like this:

@Heterfire  可以使用crnn

If your data is horizontally aligned, try adding weights to your link_conf_thresholds. Increase vertical conf_thesh and decrease horizontal conf_thresh.
Works like a charm.

@aravinthmuthu could you kindly you share specifics on how you were able to add weights to your link_conf_thresholds?

I found that we can set each neighbour pixels threshold like:
link_conf_threshold = np.array([0.8, 0.8, 0.8, 0.45, 0.45, 0.8, 0.8, 0.8])
But I don't think we can set the link_conf_threshold vertically and horizontally.

how to do localisation for multi-line text in one box..

@dajiangxiaoyan how did you re-train your model inorder to detect multi-line in one box. What are the changes needed to be made to achieve that?


CSV/DB selection for cell logger.

This uses environment variables to select between CSV and DB logging in cell-logger. The environment variables should be specified in docker-compose.

Testing has shown good results. I will merge this evening if no issues arise.


Provide customization option to enable ForcePathStyleAccess for AmazonS3

Type: Feature
Currently there is no customization option that we can configure to enable ForcePathStyleAccess for AmazonS3 via application.properties/yml. A work around is to define our own AmazonS3 bean definition, however as this is very commonly used option especially with LocalStack it would be nice to have this option.

Already in progress in https://github.com/awspring/spring-cloud-aws/pull/275

Fixed in #275.


fix: shorthand filed symbol unsed

Summary
Before will replace shorthand filed to null, it will throw Cannot use a reserved word as a shorthand property.

Test Plan
Added

!canary


Not work on windows10

It works on mac
But can not drags on windows

Does the example works on your devices? https://github.com/MixinNetwork/flutter-plugins/tree/main/packages/desktop_drop/example

It works on my windows device ( not virtual machine).
Is there any error log when you launch example app ? ( such as RegisterDragDrop failed:)

It works on my windows device ( not virtual machine).
Is there any error log when you launch example app ? ( such as RegisterDragDrop failed:)

thanks for your replay
it's very clean on log
But when I package release exe , it works
And then I open the exe on debug files , it works well
But still not work on "flutter run" model
but it's ok for me


[PIP] Pulsar consumer support auto acknowledge.

Motivation
Pulsar should support auto commit offset by client itself like what KAFKA did.
Goal
Consumer support config autoAckEnabled and autoAckIntervalMs which control auto acknowledge enabled or not and the time duration between two  acks.
Implementation
ConsumerConfigurationData add three new configuration
autoAckEnabled=false
autoAckIntervalMs=5000

private void maybeAutoCommitOffsetsAsync(long now) {
        if (autoCommitEnabled) {

        }
    }

    private void maybeAutoCommitOffsetsSync(long timeoutMs) {
        if (autoCommitEnabled) {

        }
    }

When consumer.receive() We check if auto ack needed. Here, We call maybeAutoCommitOffsetsAsync
When consumer.close We call maybeAutoCommitOffsetsSync, make sure all the consumed offset committed to pulsar successfully
Reject Alternatives
none

One Preliminary question:

If user set autoAckEnabled=ture and then user invoke negative ack, what things will happen ?

One Preliminary question:

If user set autoAckEnabled=ture and then user invoke negative ack, what things will happen ?

We should avoid this, We forbid negative ack If We set autoAckEnabled=ture`

@gaozhangmin

Pulsar should support auto commit offset in background like what KAFKA did.

But why?
The problem with Kafka acks is that if you ack each message, the performance is terrible. This is definitely not the case in Pulsar consumer.


Auto Import job failing due to go module path mismatch

@oliverchang , looks like the import job is failing from something to do with the osv -> osv.dev rename:
module declares its path as: github.com/google/osv/vulnfeeds
	        but was required as: github.com/google/osv.dev/vulnfeeds

https://github.com/pypa/advisory-database/runs/7444364565?check_suite_focus=true#step:6:22

Fixed by #91


javascript error while getting live logs

when viewing live logs at the beginning of the pipeline, the UI was blocked after displaying the first line of log. The others came in, but due to a javascript error, they were not displayed.
the JS error is:
Uncaught DOMException: Failed to execute 'querySelector' on 'Document': 'tr[data-step=][data-is-parent-step=true]' is not a valid selector.
    at getParentStep (http://localhost:8080/static/pipeline/index.js?v=dev:19:44)
    at repeatOften (http://localhost:8080/static/pipeline/index.js?v=dev:253:32)

screenshot of the UI and the error:

screenshot of the DOM:

while it should be something like the following (taken from a different pipeline/page without the bug):

cc @florianorpeliere an interesting one ;-)

Indeed, there is an error in the selector tr[data-step=] (we need something after the =).
I will make a PR to fix that 😉

after a quick look, I think it's because the currentStep is empty here https://github.com/jenkins-x/jx-pipelines-visualizer/blob/master/web/static/pipeline/index.js#L253
and also we're missing some quotes here https://github.com/jenkins-x/jx-pipelines-visualizer/blob/master/web/static/pipeline/index.js#L185 if the currentStep is empty
but it doesn't explain why the currentStep is empty

oh, in fact it's empty at the beginning, before printing the logs of the first container. when it's waiting for the 1st container to start. maybe we just need a few if(currentStep){}... ;-)


VR Issues

There are some issues I've been having with the current implementation of VR.
The current Vive in-game controllers do not respond to changes in the Camera's HeadScale property.
 It's therefore not possible to select any SurfaceGui children.
And finally, maybe I'm just ignorant but, it does not seem possible to disable these in-game vive controllers all together. One of my places implements custom controllers via GetUserCFrame but the existing Vive controllers get in the way. That, coupled with the existence of the current bugs, makes disabling the default in-game controllers an attractive option.

Hm, thanks for bringing this to my attention. I'll try to fix these bugs ASAP.

The radial menu doesn't seem to adjust to the HeadScale property either.


added seed

Description

Added seed in TF algos.
In the smoke and integration tests we have been seeing a lot of variability. Let's see if this solves the issue
Checklist:

[x] My code follows the code style of this project, as detailed in our contribution guidelines.
[ ] I have added tests.
[ ] I have updated the documentation accordingly.

@miguelgfierro [j/k]The industry standard for random seed is 42 (https://en.wikipedia.org/wiki/42_(number)) :D

That's a good point. I'll change all the seeds for the Answer to the Ultimate Question of Life, the Universe, and Everything
:-) :-)

That's a good point. I'll change all the seeds for the Answer to the Ultimate Question of Life, the Universe, and Everything
:-) :-)

Hi, I have added random seed (mentioned in #388 ), but the seed looks not working. So, should I add more random seeds in TF?

hey @AaronHeee I added a random seed here: https://github.com/Microsoft/Recommenders/blob/cec5efadcc4b1c2df4247b1e8a9f284da8fe0db5/reco_utils/recommender/ncf/ncf_singlenode.py
If you think this is ok, please accept, if you think there is anything else that needs to be done, please let us know

hello @miguelgfierro, thanks, it works for me.


Store voting subscribers in DB

Vote subscribers/reminders are currently only stored in memory and are lost on restart, they should be stored in the DB and cached in memory to keep record of subscribers after restarts.

Added with: 7b027f7855e462b2dff40a5c20d4f3e62568d2ab
Subscribers now persists across restarts and cog reloads.

Added with: 7b027f7855e462b2dff40a5c20d4f3e62568d2ab
Subscribers now persists across restarts and cog reloads.


Add datadog prefix to CPU and Alloc profilers

This is to differentiate them in the backend.

This will make it difficult to propagate the changes upstream.
Can the same be achieved by using the configuration event we are emitting in our integration and then treat the event differently?


[WIP] Create MV failed on table with geospatial index using carbonsession.

Why is this PR needed?
Create MV failed on the table with geospatial index using carbonsession.
Failed with, java.lang.ClassNotFoundException: org.apache.carbondata.geo.geohashindex
What changes were proposed in this PR?
When geo table is created with carbon session, the spatial properties are normalized and converted to lower case. Added spatial index class into noConverterList.
Does this PR introduce any user interface change?

No

Is any new testcase added?

No

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/4299/

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2551/

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/4338/

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2588/

LGTM

retest this please

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/4366/

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2616/


EPIPE Error when uploading large file using nodejs

This may not be an express issue but i couldnt find any other way to seek help, hence posting it here.
I was following this article to setup a nodejs server on my local machine (which has 16 gb memory and about 170gb free disk-space) and uploaded a 20 gb file, for the first couple of times the file got uploaded successfully, but after a while i started getting EPIPE error:
error FetchError: request to http://localhost:3200/upload failed, reason: write EPIPE
    at ClientRequest.<anonymous> (/Volumes/FreeAgent GoFlex Drive/Test/multer-project/node_modules/node-fetch/lib/index.js:1455:11)
    at ClientRequest.emit (events.js:327:22)
    at Socket.socketErrorListener (_http_client.js:467:9)
    at Socket.emit (events.js:315:20)
    at emitErrorNT (internal/streams/destroy.js:100:8)
    at emitErrorCloseNT (internal/streams/destroy.js:68:3)
    at processTicksAndRejections (internal/process/task_queues.js:84:21) {
  type: 'system',
  errno: 'EPIPE',
  code: 'EPIPE'
}

When i checked, the file got uploaded partially and was about 28mb in size. I tried uploading the file from both Postman, browser and a nodejs script, but got the same EPIPE error message. I am not sure why is this happening, googling the error message didn't help. I am not sure how to overcome this. Following is my server and client code.
// server.js
const express = require("express"); // Express Web Server
const busboy = require("connect-busboy"); // Middleware to handle the file upload https://github.com/mscdex/connect-busboy
const path = require("path"); // Used for manipulation with path
const fs = require("fs-extra");

const app = express(); // Initialize the express web server
app.use(
  busboy({
    highWaterMark: 2 * 1024 * 1024 // Set 2MiB buffer
  })
); // Insert the busboy middle-ware

const uploadPath = path.join(__dirname, "uploads/"); // Register the upload path
fs.ensureDir(uploadPath); // Make sure that he upload path exits

/**
 * Create route /upload which handles the post request
 */
app.route("/upload").post((req, res, next) => {
  req.pipe(req.busboy); // Pipe it trough busboy

  req.busboy.on("file", (fieldname, file, filename) => {
    console.log(`Upload of '${filename}' started`);

    // Create a write stream of the new file
    const fstream = fs.createWriteStream(path.join(uploadPath, filename));
    // Pipe it trough
    file.pipe(fstream);

    // On finish of the upload
    fstream.on("close", () => {
      console.log(`Upload of '${filename}' finished`);
      res.send("ok");
    });
  });
});

/**
 * Serve the basic index.html with upload form
 */
app.route("/").get((req, res) => {
  res.writeHead(200, { "Content-Type": "text/html" });
  res.write(
    '<form action="upload" method="post" enctype="multipart/form-data">'
  );
  res.write('<input type="file" name="fileToUpload"><br>');
  res.write('<input type="submit">');
  res.write("</form>");
  return res.end();
});

const server = app.listen(3200, function() {
  console.log(`Listening on port ${server.address().port}`);
});

and my client code is:
// client.js
const fs = require("fs");
const FormData = require("form-data");
const fetch = require("node-fetch");

var formdata = new FormData();
formdata.append(
  "file",
  fs.createReadStream("/Users/phantom007/My Documents/35gb.myfile")
);

var requestOptions = {
  method: "POST",
  body: formdata,
  redirect: "follow"
};

fetch("http://localhost:3200/upload", requestOptions)
  .then(response => response.text())
  .then(result => console.log(result))
  .catch(error => console.log("error", error));

Hi, just in case - EPIPE error is documented in node.js docs and basically means that you're trying to write into closed stream.
https://nodejs.org/dist/latest-v12.x/docs/api/errors.html

EPIPE (Broken pipe): A write on a pipe, socket, or FIFO for which there is no process to read the data. Commonly encountered at the net and http layers, indicative that the remote side of the stream being written to has been closed.

Yea i get that, but not sure why would that occur in my case as both the server and client are on my localhost, so there can't be any network outages.

I'm afraid you need to debug the busboy package itself.
https://github.com/mscdex/busboy/blob/master/lib/main.js

In Express, the underlying stream is a direct hand off between Node.js and the module you are using to read it (busboy, in your case). We are fairly certain your issue above lies either in busboy or your usage of busboy, but unfortunately we are experts in neither. It looks like you are using a module connect-busboy which may be the best place to ask for help, as that module's author would likely be familiar with both busboy and Express in order to publish a glue layer between the two.

@dougwilson Thanks for your reply. I have a related query, hope someone here would be able to clear my doubt.
Is it possible to download a very large file (say 50 gigs) over REST api using nodejs? What does one needs to consider when designing this architecture?

I have never done a large response like that in Node.js so cannot say for sure, but that would be a general Node.js question, rather than anything Express-specific. This is because you would write that 50GB response using the Node.js res object directly, not using like the Express.js res.send helper. You can ask general Node.js questions at https://github.com/nodejs/help


Allow for injection of task queue settings in Source initialization

It currently does not seem possible to inject the autoProcess setting of a TaskQueue from any extension of the Source class.  The changes in this PR support the injection of any of the TaskQueueSettings for both the requestQueue and syncQueue of a Source.

I could also imagine introducing a function that ensures autoProcess === true, then calls process() to begin processing any existing queued operations.  We ran into having to write this on an extension of Source in our application that uses ember-orbit.

Looks good! Thanks @gmkohler


updating for jlab extension

closes #4 Thanks to @ian-r-rose and @mpacer

jupyterlab_latex defaults to xelatex (the same as nbconvert, IIRC). For this to work out of the box, I think you will either need to (a) install XeLaTeX, or (b) set c.LatexConfig.latex_command = 'pdflatex'.

@ian-r-rose which will be easier? I'm happy with either one

@bsyouness i can close this pr with your pr


Budget App Added

Have you read the Contributing Guidelines ?
Yes I have read the Contributing Guidelines.
Description

This is a simple budget app which takes your monthly salary as input and your expenditure (in %) for different things.
Once we click on calculate , It will show a table with the amount of money you can spend on each item.
It will give an error if people spend more than they earn.

Fixes #274
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
issue #274
[Contribution made under GSSoC 22']
Video Walkthrough:
https://user-images.githubusercontent.com/71934168/162234914-b33d1175-ce97-41e6-83b1-fa394965b049.mp4

I made the change , Can you please review it once ?


custom flag as compiler argument is not accessible from BugChecker

tried passing additional key value pair to Custom BugChecker following the instructions from this doc : http://errorprone.info/docs/flags
Tried setting this in pom
     <compilerArgs>         	 <arg>-XepOpt:mvnBuildDirectory=${project.build.directory}</arg>         </compilerArgs>
And access using below code in MyCustomChecker
public MyCustomChecker(ErrorProneFlags flags) { 	    this.pwd = flags.get("mvnBuildDirectory").toString();  	  }
upon running this, I get an java.util.ServiceConfigurationError.
java.util.ServiceConfigurationError: com.google.errorprone.bugpatterns.BugChecker: Provider com.abc.errorprone.MyCustomChecker could not be instantiated

Ah, sorry about that!
Due to the requirements of ServiceLoader, the object must still have a no-arg constructor. However, if you have another constructor with ErrorProneFlags as a parameter, it will be picked up.
See #691


3dSkullStrip errors out inside screen

Running the latest mriqc (0.9.9) within Docker, I get the following error if it is run inside of screen, which doesn't forward X11. Running it outside of screen does not produce the error, but also doesn't seem to need X11 forwarding. The crash file is:
Node: workflow_enumerator.anatMRIQCT1w.AFNISkullStripWorkflow.skullstrip
Working directory: /usr/local/src/mriqc/work/workflow_enumerator/anatMRIQCT1w/AFNISkullStripWorkflow/_in_file_..data..sub-11..ses-day2..anat..sub-11_ses-$

Node inputs:

args = <undefined>
environ = {}
ignore_exception = False
in_file = /usr/local/src/mriqc/work/workflow_enumerator/anatMRIQCT1w/AFNISkullStripWorkflow/_in_file_..data..sub-11..ses-day2..anat..sub-11_ses-day1_T1w.$
num_threads = 1
out_file = <undefined>
outputtype = NIFTI_GZ
terminal_output = stream

Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/plugins/multiproc.py", line 51, in run_node
    result['result'] = node.run(updatehash=updatehash)
  File "/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/engine/nodes.py", line 407, in run
    self._run_interface()
  File "/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/engine/nodes.py", line 517, in _run_interface
    self._result = self._run_command(execute)
  File "/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/engine/nodes.py", line 650, in _run_command
    result = self._interface.run()
  File "/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/interfaces/base.py", line 1086, in run
    runtime = self._run_interface(runtime)
  File "/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/interfaces/afni/base.py", line 129, in _run_interface
    return super(AFNICommandBase, self)._run_interface(runtime)
  File "/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/interfaces/base.py", line 1587, in _run_interface
    self.raise_exception(runtime)
  File "/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/interfaces/base.py", line 1526, in raise_exception
    **runtime.dictcopy()))
RuntimeError: Command:
3dSkullStrip -input /usr/local/src/mriqc/work/workflow_enumerator/anatMRIQCT1w/AFNISkullStripWorkflow/_in_file_..data..sub-11..ses-day2..anat..sub-11_ses$
Standard output:

Standard error:
freeglut (3dSkullStrip): failed to open display ':1286930384'

Return code: 1

Hi @stjep, the latest mriqc update was supposed to address this. It seems that Xvfb is not correctly running on your settings.

@oesteban, my bad, my vm instance did not have xvfb installed.
Seems to be running fine now so I'm closing this. Will re-open if the bug re-appears, but looks good so far.

I'm getting this with 0.9.9 on OpenNeuro: https://openneuro.org/datasets/ds000007/versions/00001?app=MRIQC&version=46
Surprisingly it only happened for one subject out of many. I would suggest switching to including (in the Docker image) a version of AFNI that does not depend on display.

I talked to one of the afni developer's about this issue. For shared machines where you don't have access to docker this problem is solved nicely in afni's @chaufeur_afni (tcsh), have a look with:
vim `which \@chauffeur_afni `

Specifically the following can be used to keep trying different displays until it succeeds :
set ranval = `count -dig 1 1 999999 R1`

if( $?xdisplay == 0 )then
  set killX     = 1
  set ntry      = 1
  set Xnotfound = 1
  while( $Xnotfound )
    set xdisplay = `count -dig 1 3 999 R1`
    if( -e /tmp/.X${xdisplay}-lock ) continue
    echo " -- trying to start Xvfb :${xdisplay}"
    Xvfb :${xdisplay} -screen 0 1024x768x24 &
    sleep 1
    jobs > zzerm.$ranval.txt
    grep -q Xvfb zzerm.$ranval.txt
    set Xnotfound = $status
    \rm -f zzerm.$ranval.txt
    if( $Xnotfound == 0 )break ;
    @ ntry++
    if( $ntry > 99 )then
      echo "** ERROR: can't start Xvfb -- exiting"
      goto BAD_EXIT
    endif
  end
endif

setenv DISPLAY :${xdisplay}
set OW = "OPEN_WINDOW"

xvfb-run -a does this but seems to cause issues with image opacity.

I'm running into this more often on OpenNeuro. Would be great to ship with version of 3dskullstrip that does not require display.

I also wonder why it started happening now - was AFNI updated?

Run into this again on OpenNeuro.


"Enter VR" tooltip is borked

Load https://aframe.io/aframe-editor/example/
Click "Exit"
Click the "Enter VR" button
Notice the positioning of the tooltip is all off:

I would like to fix this.

Perfect!, It's all yours ;)

@fernandojsg It looks like it is just the online version that is corrupted. I ran it locally (opened /examples/index.html and it worked great. Still looking into this.

@fernandojsg I don't think this is an issue any more. It seems that it was solved recently.

@Coder206 I just tried on chrome 51 osx and it still there :\ In which browser are you trying?

@fernandojsg FireFox 47.0.1 on Fedora

Yep, on firefox on osx it seems to works right too. So it looks like a problem with chrome, could you try it on fedora?

@fernandojsg On it.

@fernandojsg Make that Windows 10 FireFox 47.0.1 and 48.0 both work (I just updated). It seems to be Chrome specific as Version 52.0.2743.82 (64-bit) on Fedora 24 is not working like your screen shot shows.

@fernandojsg Do you mind testing it on Safari as I do not have a Mac to try it out there?

@Coder206 safari shows it correctly aligned.

@fernandojsg Thanks, so this is a Chrome specific issue.

@fernandojsg Btw, is there an IRC for A-Frame contributors?

We've a slack: https://aframevr-slack.herokuapp.com/

@fernandojsg Thanks!

@fernandojsg Chrome seems to be complaining about use of XMLHttpRequest in "aframe-inspector.js" code (line 24).
Error message:
"Synchronous XMLHttpRequest" on the main thread is deprecated because of its detrimental effects on the user's experience. For more help, check https://xhr.spec.whatwg.org/."

This code is throwing an error:
e.open("GET", "https://raw.githubusercontent.com/aframevr/aframe-components/master/components.json", !1),

Yes, but that's just a warning and we'll remove the feature that uses that (third-party components) until next version. I don't think the CSS error is related to this, maybe we could just open another issue with this warning to take care of this in the future.

@fernandojsg That makes sense.

@fernandojsg It appears as though when running the example code locally it works well. See below:

@Coder206 I don't see the icon in the screenshot, is cropped

@fernandojsg Try refreshing the page, sorry.

(I updated the comment)

@fernandojsg I isolated the CSS code that made the error. There was a "display:block;" in the element.style of the affected button. I am tracing back the code to a file now.

@fernandojsg I think it's this line causing the issue: https://github.com/aframevr/aframe/blob/master/src/style/aframe.css#L206

@Coder206 Thanks for the investigation. Though the latest version of A-Frame has removed that modal/tooltip (at least for now).

@ngokevin Oh ok. My pleasure, it was an interesting hunt with @fernandojsg! :) Thanks.


Does not work with Nuxt.js

Hi, thanks for your awesome plugin :)
I used this with Vue.js and worked fine. But in my current project, it's not working.

Environments:

"nuxt": "^2.4.3",
"vuetify": "^1.5.0",
"vuetify-daterange-picker": "^2.6.2"

appreciate your help :)

Hi!
I built a new version from ground up keeping simplicity of use in mind. Can you please try it out and let me know if that works for you?
P.S - I still need to add the option to pass in presets.
https://vuetify-daterange-picker.gitbook.io/docs/

Also, in your codesandbox demo, I see this. Is that intended?

FYI, I need to disable ssr in my nuxt-config.js in order to use this.
plugins: [
  { src: '~/plugins/datepicker.js', ssr: false }
],

Hi!
Can you please try the latest version of the component 3.1.1 and see if that works?
Note - the new version has breaking changes.

@praveenpuglia sorry, I was on vacation. I will try the new version and let you know. Thanks for your attention.


[DNM] Test OSP 1.12 upgrade

only 1 e2e-tests failure, but a chains one:
 Summarizing 1 Failure:
  [FAIL] [chains-suite Tekton Chains E2E tests] test creating and signing an image and task verify-enterprise-contract task [It] succeeds when policy is met [ec, HACBS, pipeline]
  /tmp/tmp.0b7HYAykXv/tests/build/chains.go:225

let's see how persistent that is, and if it is persistent, then we may have to dig into how the deployment of chains in 1.12 is affecting things here

per https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/redhat-appstudio_infra-deployments/2507/pull-ci-redhat-appstudio-infra-deployments-main-appstudio-e2e-tests/1709579474581852160/artifacts/appstudio-e2e-tests/redhat-appstudio-gather/artifacts/must-gather-appstudio/quay-io-openshift-release-dev-ocp-v4-0-art-dev-sha256-8af2c323e4325849f71649bc0e6e140806e5196e5c2a6926aea1e0e0e4f10d8e/cluster-scoped-resources/operators.coreos.com/operators/openshift-pipelines-operator-rh.openshift-operators.yaml confirmed this was using 1.12

Same error again @Roming22
 Summarizing 1 Failure:
  [FAIL] [chains-suite Tekton Chains E2E tests] test creating and signing an image and task verify-enterprise-contract task [It] succeeds when policy is met [ec, HACBS, pipeline]
  /tmp/tmp.X5C0t7OILc/tests/build/chains.go:225

I think we have to assume that 1.12 changed something wrt chains that is affecting the e2e's.  My PR https://github.com/redhat-appstudio/infra-deployments/pull/2508 should be a good sanity check to make sure this test is not flaking in general.

and again
 Summarizing 1 Failure:
  [FAIL] [chains-suite Tekton Chains E2E tests] test creating and signing an image and task verify-enterprise-contract task [It] succeeds when policy is met [ec, HACBS, pipeline]
  /tmp/tmp.ond9F4dCOQ/tests/build/chains.go:225

/retest

All tests are successful. Closing the PR.


Add Github pull request templates

Doc: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository
Of different types

[x] release
[x] merge

The selection of pull request is not working post #16  merge to main :'(
Going to try fixing this with renaming for 0.0.2 and maybe a sample repo test

Looks like not the most fun but... https://stackoverflow.com/questions/73771068/multiple-templates-for-pull-requests-on-github