I hit a problem - and I detected the very strange situation:
I run Docker image locally and run there autoreconf -i and I get correct and robust ./configure script.
Then I run autoreconf -i in the same Docker image but under Gitlab CI. And I get broken ./configure script - some of M4 macro were not substituted to their shell code, so Bash cannot execute them and treats them as syntax errors.
The difference is in m4/ folder in the both runs: successful m4/ folder contains files like:
aria2_arg.m4
ax_check_compile_flag.m4
ax_cxx_compile_stdcxx_11.m4
codeset.m4
fallocate.m4
fcntl-o.m4
gettext.m4
... # and so on
but in the failed (Gitlab CI) m4/ folder there are:
gettext.m4
fcntl-o.m4
# ... and so on
and aria2_arg.m4, ax_check_compile_flag.m4, ax_cxx_compile_stdcxx_11.m4, fallocate.m4 and others are missing. I don't know how is it possible if the Docker image is the same in both cases, but... how does autoreconf create m4/ folder? If its content's source is the Docker image itself (I don't know is it true, it's my suggestion only), then why is the content different in both cases?
No any magic. The missing m4 files do exist in the original Aria2 Github repository (in m4/) folder. autoreconf -i adds another .m4 files to this folder. But it has .gitignore with .m4 rule. I added it to another git repo (to build it in Gitlab) but m4/ folder was ignored. So:
Aria2 -> local folder -> run docker -> OK
Github with m4/ locally m4/ exists
works fine, but:
Aria2 -> another git repo -> run Gitlab CI -> Failure
Github (now no m4/) (.m4 missing)
So, it seems the reason of the problem was - the miss of m4/ in the second git repo (at least I have got the first successful build)
Related
I am trying to generate code coverage report using LCOV in Ubuntu platform. I referred
https://github.com/QianYizhou/gtest-cmake-gcov-example
It is working.
I am giving cmake --build ../application/build --target install in my shell script.
After script execution, I can see that the cmakefiles are generated in the build folder.
cd build && make test
cd build && make coverage_TEST_NAME //To check the coverage
I did execute above in my build folder and I generated report.
My problem is, I use this in gitlab pipeline. There is no build folder I can see. So I don't know how to do make coverage_TEST_NAME in my yml file
Generate code generation output in gitlab pipeline.
Problem resolved. Just like in my Ubuntu virtual machine, the application folder was there in my docker image.
I just added a ../application/build command in my yml script, it navigated there.
I have a leshan server jar file (to which I have made some changes) obtained by running the maven clean install. I specify that I work in linux and I put this jar file inside a "leshan_docker" folder contained in the desktop. within the same folder there is also a dockerfile to build the server image, and it is written as follows:
FROM openjdk:8-jre-alpine
COPY /Desktop/leshan_docker/leshan-server-demo-*.jar /Desktop/leshan_docker/
CMD ["java", "-jar", "/leshan-server-demo-2.0.0-SNAPSHOT.jar"]
but when I go to build through this command:
sudo docker build -f Dockerfile3 -t leshan-server3 .
It reports me the following error:
Sending build context to Docker daemon 12MB
Step 1/3 : FROM openjdk:8-jre-alpine
---> f7a292bbb70c
Step 2/3 : COPY /Desktop/leshan_docker/leshan-server-demo-*.jar /Desktop/leshan_docker/
COPY failed: no source files were specified
How can I go about solving the problem? Thanks in advance for your answers.
Your source path with the COPY command should be relative to the build context. Your build context is in the folder you're running sudo docker build in since the final argument you gave was .. I highly recommend taking a look at the docs.
The destination path for the COPY command should be relative to the path in your container. What may work now is to move your .jar to the root directory and run it from there.
So if your jar files are in the same directory you're running the command in, change it to:
COPY leshan-server-demo-*.jar /
It would be better practice to actually create a new directory in the container to hold your .jar file to keep your work more organized.
I install the Apache Maven on Ubuntu server with Apt with sudo apt install maven
I am new to Linux but as I am understanding this installation produces an m2 repository.
what is want is the following:
first how to find and inspect this m2?
second how to replace this m2 with an m2 repository that I have download to my desktop?
By default, maven's local repository is located in the user's home directory. In fact it's actually named ".m2" directory, instead of just "m2". It is a hidden directory. If you are not in your home directory, issue "cd ~" first. Then issue "ls -al" to see the presence of .m2 directory.
If for any reason, you do not see that "m2" directory after issuing above command, it simply means that you did not built or run any project that requires maven to get triggered and create that .m2 folder.
ps: Replacing the existing .m2 folder with the one you have on your desktop may not be a good idea. Instead, simply run the project (that you think requires the needed dependencies). This will build the .m2 directory afresh along with everything that app needs.
Is it possible to stop verify/download newer repo from internet, such as
test $ repo init -u git#1.1.1.1/test/iot_manifest.git
Get https://gerrit.googlesource.com/git-repo/clone.bundle
Get https://gerrit.googlesource.com/git-repo
remote: Counting objects: 1, done
remote: Finding sources: 100% (36/36)
...
You can't, the repo installed on your computer (the one in your $PATH) is not the full version of repo it is only a launcher.
From the repo documentation on source.android.com:
Repo comes in two parts: One is a launcher script you install, and it communicates with the second part, the full Repo tool included in a source code checkout.
When you run repo init for the first time it gets the full repo and store it in the .repo/repo directory. Every time you'll run repo init again in a brand new repository, the full repo will be downloaded again in .repo/repo.
One thing though you can stop getting the clone.bundle line with repo init --no-clone-bundle
Get repo from your own computer (without internet)
You can use a local version of repo, you need the internet at least to get the git-repo code once. After that you can use this version stored locally in place of the remote ones on Google server.
cd workspace
git clone https://gerrit.googlesource.com/git-repo
mkdir repo_init_no_internet && cd repo_init_no_internet
repo init --repo-url=/home/<user>/workspace/git-repo
I'm trying to run a simple image that executes .sh file but I got this error.
standard_init_linux.go:185: exec user process caused "no such file or directory"
Here is my Dockerfile
FROM python:2
ADD . .
CMD ["./test.sh"]
test.sh:
#!/bin/bash
echo "test"
I'm running Docker in Windows 10 and I have checked '/bin/bash' is existed in the container.
Why I got this error?
I have faced the exact same issue when I tried to create a Linux container image with Docker on windows 10. When you copy the file from windows to docker image, the file format is that of dos. You may need to run dos2unix utility on all the files before copying them inside docker image.
To make things clear, I would share my experience. When I checked out my project source code using git on windows and tried to create a linux docker container by building the image locally, I got the exact same error message. This happened because I created my git project on Linux but this time, I checked out on windows. My default git global configuration on windows was checkout Windows-style commit Unix-style, i.e. Git will convert LF to CRLF when checking out text files. When committing text files, CRLF will be converted to LF. For cross-platform projects, this is the recommended setting on Windows ("core.autocrlf" is set to "true")
In order to resolve this, I changed my windows' git global config as I wanted to checkout Unix-style commit Unix-style.(How to change line-ending settings)
git config --global autocrlf input
After this, I checked out my project again and created a fresh local image that ran perfectly.