Any contract I successfully build that has a dependency to elrond-wasm 0.19.1 fails to deploy
Is there any known issue regarding this or am I the only one facing this?
Trying to build on the older 0.18.2 works but a lot of the contract code has to be changed in order to achieve a build.
Most examples I have tried to build and deploy from the Elrond Github Rust examples repository fail when deployed with the same error.
Although the one found at https://github.com/ElrondNetwork/ping-pong-smart-contract that is using these dependencies:
[dependencies.elrond-wasm]
version = "0.18.2"
features = ["derive"]
[dependencies.elrond-wasm-node]
version = "0.18.2"
optional = true
[dev-dependencies.elrond-wasm-debug]
version = "0.18.2"
works great. Build and deploy work flawlessly.
If you are trying to deploy on the devnet this will fail because it hasn't been updated to 0.19 yet, so you still have to use 0.18.x there.
Also note that 0.19.1 wasn't officially released yet, so that will most likely fail on mainnet and devnet as well.
So either way the solution as you have already described is to downgrade your elrond-wasm versions to 0.19.0 or 0.18.2, depending on the net on which you want to deploy.
Related
Since a few days, our aws elastic beanstalk fails to deploy our code through npm Install.
We are using our own fork from parse-server repo, and it always worked fine.
Unfortunately it now fails without obvious reason. When looking at the instance logs it clearly shows it tries to use the original parse-server repo (on a very old branch) instead of our very own fork, but I can't figure why.
Our package.json file indicates:
"parse-server": "git+https://github.com/hulab/parse-server.git#patched/5.3.0-hulab-2"
and our npm-shrinkwrap.json file reflects it with a
"parse-server": {
"version": "git+https://github.com/hulab/parse-server.git#54bfd65181f19d4296f0ebea79cf3a4ab542f2fc",
"from": "git+https://github.com/hulab/parse-server.git#patched/5.3.0-hulab-2",
...
}
Whereas the EC2 instance logs indicate failures when installing:
parse-server#github:parse-community/parse-server#892c6f94d50b6dced8a5e1948e058dc7b095c914
I can't figure out why this branch is used while not being referred to in any of our files!
Any help would be very appreciated :)
It is likely another dependency that points to that specific version of Parse Server.
For example, the Parse JS SDK has a devDependency for integration tests:
"parse-server": "github:parse-community/parse-server#alpha"
Since you are using a customized version of Parse Server, check the Parse JS SDK (which is a component of Parse Server), and any other Parse dependency that you added, whether they have a parse-server dependency and to where it points. In package.json you may only see the branch name but in package-lock.json of that dependency you may see the actual commit hash you are referring to.
I am trying to run runner on gitlab which is config with Fastlane through a pipeline, when I commit pipeline runs but failed every time. I am not sure what is the issue but it seems that my gitlab-ic.yml file is not working correctly
Did you installed java? Jdk or jre? Obviously your java path is wrong. You can post your config, so it is easier to find the problem.
I'm in the process of creating a custom transformer for kustomize. However, I'm running into issues creating even the most basic Go Plugin. I'm trying to follow these steps here https://github.com/kubernetes-sigs/kustomize/blob/master/docs/plugins/goPluginGuidedExample.md
I'm using one of the plugins in mainline kustomize, ie. secretsfromdatabase [1]
According to the documentation, the instructions I'm following are:
tmpGoPath=$(mktemp -d)
GOPATH=$tmpGoPath go install sigs.k8s.io/kustomize/kustomize
GOPATH=$tmpGoPath go build -buildmode plugin -o SecretsFromDatabase.so SecretsFromDatabase.go
cp SecretsFromDatabase.so ~/.config/kustomize/plugin/mygenerators/sopsencodedsecrets/SopsEncodedSecrets
Now when I run kustomize, I get the following error:
Error: accumulating resources: recursed accumulation [...] fails to load: plugin.Open("$HOME/.config/kustomize/plugin/mygenerators/sopsencodedsecrets/SopsEncodedSecrets"): plugin was built with a different version of package internal/cpu
What is strange is I'm using the same tag in git as the version that is installed on my system.
kustomize version tags/kustomize/v3.5.4^0
{Version:3.5.4 GitCommit:3af514fa9f85430f0c1557c4a0291e62112ab026 BuildDate:2020-01-17T14:23:25+00:00 GoOs:darwin GoArch:amd64}
[1] https://github.com/kubernetes-sigs/kustomize/tree/master/plugin/someteam.example.com/v1/secretsfromdatabase
As for now plugins are very difficult to write and support because the environment should be identical and in practice only original build system can reliably build the plugins. In result a lot of people like you finding little differences in their build environments. I think it is bad idea from design and strongly recommend to get acquainted with Reddit discussion here
I have a java webapp on heroku. It runs perfectly on the cloud. But when run locally it appears to use a stale resource. My jar is called nymmbl1-1.0.jar. I have 100% verified the resource is correct in target\nymmbl1-1.0.jar and ~.m2\repository\com\nymmbl\nymmbl1\1.0\nymmbl1-1.0.jar. When run locally the resource is old. It's as though heroku local is using some cached version.
Has anyone ever seen anything like this?
The out-of-date resource is a local read-only SQlite database. When running "heroku local" the database is accessed but the content returned is different than the actual database content in the current jar. The content returned is from an older version of the SQLite DB that is not in the current JAR.
As I said, this problem is not observed when run on the cloud.
My guess is that "heroku local" is doing something I don't expect. Can you suggest what may be the problem or how to debug this?
This problem disappeared upon updating some maven artifacts. For the record here's what I changed:
org.springframework.boot spring-boot-starter-parent, changed from
1.5.2.RELEASE to 1.5.7.RELEASE
webjars-bootstrap.version, from 3.3.6 to 3.3.7-1
webjars-jquery-ui.version 1.1.14 => 1.12.1
webjars-jquery.version 2.2.4 => 3.2.1
thymeleaf.version 3.2.5.RELEASE => 3.0.7.RELEASE
I'm trying to run the findbugsMain task in Gradle 1.10 (or more specific "gradlew check") but the only thing I get is an error like
building findbugsMain 33% > ...
:findbugsMain FAILED
It seems to download the required jars though:
...
Download http://repo1.maven.org/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
Download http://repo1.maven.org/maven2/asm/asm/3.3/asm-3.3.jar
Download http://repo1.maven.org/maven2/asm/asm-tree/3.3/asm-tree-3.3.jar
Download http://repo1.maven.org/maven2/asm/asm-commons/3.3/asm-commons-3.3.jar
Download http://repo1.maven.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.jar
Download http://repo1.maven.org/maven2/jdom/jdom/1.0/jdom-1.0.jar
Download http://repo1.maven.org/maven2/xerces/xercesImpl/2.6.2/xercesImpl-2.6.2.jar
Download http://repo1.maven.org/maven2/xom/xom/1.0/xom-1.0.jar
Download http://repo1.maven.org/maven2/xerces/xmlParserAPIs/2.6.2/xmlParserAPIs-2.6.2.jar
Download http://repo1.maven.org/maven2/xalan/xalan/2.6.0/xalan-2.6.0.jar
Download http://repo1.maven.org/maven2/com/ibm/icu/icu4j/2.6.1/icu4j-2.6.1.jar
:findbugsMain FAILED
I ran the task using --stacktravce again and this is what I got:
Pastebin link
My build.gradle is also on Pastebin
I'm relatively new to build management tools in general and gradle in particular, so it might be my fault (e.g. buildscript has an error).
Judging from the stack trace, some internal error occurs. This could be due to an incompatibility between the version of the ASM library used by Gradle, and the version expected by FindBugs. Would you mind to file an issue over at http://forums.gradle.org, ideally including a minimal reproducible example?
As it seems FindBugs up to version 2.0.3 has problems with some Java 8 classfiles. These
problems will be addressed in the next major version of FindBugs. Until then you have to use Java 7.
So, the short version is, that I changed the language level to 1.7 and everything runs just fine now.
Thanks #peter for the help.