I've been following this tutorial in order to deploy my first DAPP
https://docs.terra.money/docs/develop/dapp/quick-start/using-terrain-localterra.html
I've ran this in order to install localterra and run docker
git clone --branch v0.5.2 --depth 1 https://github.com/terra-money/localterra
cd localterra
docker-compose up
Secondly I've scaffolded my dApp
terrain new my-terra-dappcd
cd my-terra-dapp
npm install
I've encountered problems at the third step, the Deploy
When Running
terrain deploy counter --signer validator
I get this
How can I possibly solve this error?
Would really appreciate an answer, thank you!
Finished release [optimized] target(s) in 0.09s
Running script 'optimize': 'docker run --rm -v "$(pwd)":/code --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry cosmwasm/rust-optimizer:0.12.3
'
Info: RUSTC_WRAPPER=sccache
Info: sccache stats before build
Compile requests 0
Compile requests executed 0
Cache hits 0
Cache misses 0
Cache timeouts 0
Cache read errors 0
Forced recaches 0
Cache write errors 0
Compilation failures 0
Cache errors 0
Non-cacheable compilations 0
Non-cacheable calls 0
Non-compilation calls 0
Unsupported compiler calls 0
Average cache write 0.000 s
Average cache read miss 0.000 s
Average cache read hit 0.000 s
Failed distributed compilations 0
Cache location Local disk: "/root/.cache/sccache"
Cache size 0 bytes
Max cache size 10 GiB
Building contract in /code ...
Updating crates.io index
Killed
Finished, status of exit status: 137
Error: ENOENT: no such file or directory, open 'artifacts/counter.wasm'
Code: ENOENT
It seems Docker ran out of memory; the tutorial you linked mentions this potential problem, and suggests increasing the amount of memory available to Docker.
Related
My documentation tests are silently not executed in my Docker environment while everything works on both Windows and Ubuntu/Debian hosts.
I created a minimal Github Repository to demonstrate the issue. I tried two different versions of Rust nightly and Rust stable, debug/release, all without success. See my Dockerfile and complete build output.
Example code:
/// Fixes string arrays which can also be objects into string arrays
/// # Examples
///
/// ```
/// assert_eq!(cargo_test_doc_docker::add(1, 2), 3);
/// ```
pub fn add(a: i32, b: i32) -> i32 {
a + b
}
Result when executing on Debian:
arturh#host:~/projects/cargo-test-doc-docker$ cargo test
Compiling cargo-test-doc-docker v0.1.0 (/home/arturh/projects/cargo-test-doc-docker)
Finished test [unoptimized + debuginfo] target(s) in 2.39s
Running target/debug/deps/cargo_test_doc_docker-9d5ae146cd4c3628
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Running target/debug/deps/cargo_test_doc_docker-2a696d2579128ce1
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Doc-tests cargo-test-doc-docker
running 1 test
test src/lib.rs - add (line 4) ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
The problem occurs when executing the build on Docker. This is a minimal Dockerfile that reproduces the problem:
FROM ekidd/rust-musl-builder:nightly-2020-01-26-openssl11 as build
COPY --chown=rust:rust . .
RUN cargo test; echo $?
Result for every Rust toolchain I tried:
Step 6/17 : RUN cargo test; echo $?
---> Running in b266fc72f3c1
Compiling cargo-test-doc-docker v0.1.0 (/home/rust/src)
Finished test [unoptimized + debuginfo] target(s) in 0.32s
Running target/x86_64-unknown-linux-musl/debug/deps/cargo_test_doc_docker-7b40e7e5b47f49eb
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Running target/x86_64-unknown-linux-musl/debug/deps/cargo_test_doc_docker-0bfec9752a7bec14
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
0
It does not even try to execute any doc tests and exits with zero so it's not easily noticed. I guess it must be something the Docker base image does, but what could that be?
Cross Compilation
This is a logical, if surprising, outcome of cross-compilation.
To understand why, imagine that you:
Compile on a Linux x64 machine (Host).
Target a Windows ARM machine.
The generated code cannot be executed on the current host (Linux x64): it is prepared for a different CPU (instruction set) and OS (system calls).
Since the tests -- unit tests, integration tests, and documentation tests -- are also generated for the target architecture, they cannot be executed on the host either.
What to do with the tests?
If your code has no specific dependency on a specific platform, then you can content yourself with compiling for the host and running those.
Otherwise, you will need access to a machine that can actually run the cross-compiled binaries. You can still use cross-compilation to speed up building those binaries, and then upload them to either a physical or virtual machine to run them.
AFAIK Cargo does not help with the latter, so you'll need your own scripts.
Shepmaster was right, when I target the x86_64-unknown-linux-musl it also does not work locally on Debian:
arturh#host:~/projects/cargo-test-doc-docker$ cargo test --target=x86_64-unknown-linux-musl; echo $?
Compiling cargo-test-doc-docker v0.1.0 (/home/arturh/projects/cargo-test-doc-docker)
Finished test [unoptimized + debuginfo] target(s) in 0.28s
Running target/x86_64-unknown-linux-musl/debug/deps/cargo_test_doc_docker-8dfff5631875d404
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Running target/x86_64-unknown-linux-musl/debug/deps/cargo_test_doc_docker-eb877250b708174b
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
0
I guess I must have a separate build step for testing the doc tests with the target x86_64-unknown-linux-gnu.
I have created a jenkins "freestyle" job, in which I am trying to run multiple BDD testing process. Following is the "commands" I have put in "Jenins/Build/execute shell" section:
cd ~/FEXT_BETA_BDD
rm -rf allure_reports allure-reports allure-results
pip install behave
pip install selenium
pip install -r features/requirements.txt
# execute features in plan section
behave -f allure_behave.formatter:AllureFormatter -f pretty -o ./allure-reports
./features/plan/*.feature
# execute features in blueprint section
behave -f allure_behave.formatter:AllureFormatter -f pretty -o ./allure-reports
./features/blueprint/*.feature
What I have found is in Jenkins, if there is any test case intermittent failure, such message is shown in the Console Output:
"
...
0 features passed, 1 failed, 0 skipped
0 scenarios passed, 1 failed, 0 skipped
3 steps passed, 1 failed, 1 skipped, 0 undefined
Took 2m48.770s
Build step 'Execute shell' marked build as failure
"
And the leftover test cases are skipped. But if I was to run the behave command on my local host directly, I don't get this type of behaviour. The failure will be detected and the remaining test cases continues till all are finished.
So How may I work around this issue in Jenkins ?
Thanks,
Jack
You may try the following syntax:
set +e
# execute features in plan section
behave -f allure_behave.formatter:AllureFormatter -f pretty -o ./allure-reports
./features/plan/*.feature || echo 'ALERT: Build failed while running the plan section'
# execute features in blueprint section
behave -f allure_behave.formatter:AllureFormatter -f pretty -o ./allure-reports
./features/blueprint/*.feature || echo 'ALERT: Build failed while running the blueprint section'
# Restoring original configuration
set -e
Note:
Goal of set -e is to cause the shell to abort any time an error occurs. If you will see your log output, you will notice sh -xe at the start of execution which confirms that Execute Shell in Jenkins uses -e option. So, to disable it, you can use +e instead. However, it's good to restore it once your purpose is fulfilled so that subsequent commands produce expected result.
Ref: https://superuser.com/questions/1113014/what-would-set-e-and-set-x-commands-do-in-the-context-of-a-shell-script
The ConsoleOutput from the SummaryReporter above indicates that you have only one feature with one scenario (that fails). Behave has no such thing that it stops when the first scenario fails.
An early abortion of the test run can only occur if critical things happen:
A failure/exception in the before_all() hook occurs
A critical exception is raised (SystemExit, KeyboardInterrupt) to end the test run
Your implementation tells behave to abort the test run (make sense on critical failures when all other tests will also fail; why waste the time)
BUT: If the test run is aborted early, all the features/scenarios that are not executed yet are reported as untested counts in the SummaryReporter.
...
0 features passed, 1 failed, 0 skipped, 2 untested
0 scenarios passed, 1 failed, 0 skipped, 3 untested
0 steps passed, 1 failed, 0 skipped, 0 undefined, 6 untested
HINT: Untested counts are normally hidden. They are only shown if the counter is not zero (greater than zero).
This is not the case in your description.
SEE ALSO:
behave: features/runner.abort_by_user.feature
OS: Ubuntu 16.04, NVIDIA Driver
I followed the drake installation procedure as described in drake website.(I have also installed nvidia driver)After installation, as per the instructions when I run:
$ xhost +local:root; nvidia-docker run -i --rm -e DISPLAY -e QT_X11_NO_MITSHM=1 -v /tmp/.X11-unix:/tmp/.X11-unix --privileged -t drake; xhost -local:root
I am getting the following error:(simulation is not being displayed, but the build is successful)
non-network local connections being added to access control list
+ [[ 0 -eq 0 ]]
+ bazel build //tools:drake_visualizer //examples/acrobot:run_passive
Starting local Bazel server and connecting to it...
INFO: Analysed 2 targets (95 packages loaded, 18023 targets configured).
INFO: Found 2 targets...
INFO: Elapsed time: 89.206s, Critical Path: 1.58s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
+ sleep 2
+ ./bazel-bin/tools/drake_visualizer
+ bazel run //examples/acrobot:run_passive
INFO: Analysed target //examples/acrobot:run_passive (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //examples/acrobot:run_passive up-to-date:
bazel-bin/examples/acrobot/run_passive
INFO: Elapsed time: 1.031s, Critical Path: 0.01s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
process 297: D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/etc/machine-id' should contain a hex string of length 32, not length 0, with no other text
See the manual page for dbus-uuidgen to correct this issue.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Could not initialize OpenGL for RasterGLSurface, reverting to RasterSurface.
Could not initialize OpenGL for RasterGLSurface, reverting to RasterSurface.
Could not initialize OpenGL for RasterGLSurface, reverting to RasterSurface.
Could not initialize GLX
./setup/ubuntu/docker/entrypoint.sh: line 15: 297 Aborted (core dumped) ./bazel-bin/tools/drake_visualizer
non-network local connections being removed from access control list
We are in the process of updating the instructions to use nvidia-docker 2.0. Please check the drake repo again later this week for an update. In meantime, you may wish to try the open-source driver instructions on the same page.
When my Docker build reaches this part of the Dockerfile:
ARG cabal=1.22.9.0
RUN curl -L http://hackage.haskell.org/package/cabal-install-${cabal}/cabal-install-${cabal}.tar.gz | tar -xzf- && \
cd cabal-install-${cabal} && \
EXTRA_CONFIGURE_OPTS= ./bootstrap.sh --global
It eventually ends with this error.
Downloading zlib-0.6.1.1...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 139k 0 139k 0 0 293k 0 --:--:-- --:--:-- --:--:-- 293k
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
Configuring zlib-0.6.1.1...
Setup: Missing dependency on a foreign library:
* Missing (or bad) header file: zlib.h
* Missing C library: z
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
Error during cabal-install bootstrap:
Configuring the zlib package failed.
The command '/bin/sh -c curl -L http://hackage.haskell.org/package/cabal-install-${cabal}/cabal-install-${cabal}.tar.gz | tar -xzf- && cd cabal-install-${cabal} && EXTRA_CONFIGURE_OPTS= ./bootstrap.sh --global' returned a non-zero code: 2
Is there something I can include in my Dockerfile that can prevent this?
I'm attempting to install RVM, and I have a more recent version of BASH. I assume that it needs a version that is 3.2.25 or more recent. I've seen a few post online about it, but they've all been dated or no longer relevant to the current code. Here is what I put in cmd (I have Windows 10 pro).
curl -L https://get.rvm.io | bash -s stable --autolibs=enabled --ruby --rails
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 184 100 184 0 0 143 0 0:00:01 0:00:01 --:--:-- 155
100 22865 100 22865 0 0 9566 0 0:00:02 0:00:02 --:--:-- 45730
Input file specified two times.
BASH 3.2.25 required (you have 4.3.42(4)-release)
The error "Input file specified two times," displayed when the check was run, is output from the Windows sort command. If you run this command it will show you which instance of the sort command is being run:
which sort
To ensure the correct version is always used, alter your PATH to include the typical Bash executable paths (/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin) before any Windows ones. Or, simply remove the Windows paths from your PATH.
Where you change this depends on how you've installed Bash (Cygwin, git-bash, etc.) but is typically a file in your home directory called .profile or .bash_profile.
My problem is ~/.bash_profile,
Because your head is wrong.
If you are using:
export PATH=some/other/path:${PATH}
Let's change to:
export PATH=${PATH}:some/other/path
Hope this help!