My deploy stage failed,just that line
chmod og= $STAGE_ID_RSA
Got error
chmod og= $STAGE_ID_RSA
BusyBox v1.34.1 (2022-04-04 10:19:27 UTC) multi-call binary.
Usage: chmod [-Rcvf] MODE[,MODE]... FILE...
MODE is octal number (bit pattern sstrwxrwxrwx) or [ugoa]{+|-|=}[rwxXst]
-R Recurse
-c List changed files
-v Verbose
-f Hide errors
ERROR: Job failed: exit code 1
I read this
Gitlab CI/CD pipeline error
but I do not have .ssh on Gitlab server(located on other server).
How to change file content permission?
check if "STAGE_ID_RSA" is saved as "file" not "variable" on the gitlab's variable configuration page.
Related
While building the image in Jenkins gradle build fails with the error
ERROR: JAVA_HOME is set to an invalid directory: /opt/java/openjdk
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
Following is the part of the Dockerfile. The RUN gradle build is what fails.
FROM gradle:7.4.2-jdk8 as builder
COPY --chown=gradle:gradle . /home/gradle/src
WORKDIR /home/gradle/src
RUN gradle build --no-daemon
What I have checked
That the path is correct /opt/java/openjdk
https://hub.docker.com/layers/gradle/library/gradle/jdk8-jammy/images/sha256-8fe6aa6c268162cbb00e0873e94e8c8a49aea1d3bdf7a3c7499751f227f5dfc6?context=explore
What fails is the following gradle check : https://github.com/marklogic-community/ml-gradle/blob/9816f8756e8a6c656cb2371a4d9f85405e39e6d8/gradlew#L73
if [ ! -x "$JAVACMD" ] ; then
die "ERROR: JAVA_HOME is set to an invalid directory: $JAVA_HOME
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation."
fi
It builds perfectly fine locally when do I skaffold build with local profile. But fails in Jenkins.
So the path exists so I am not sure why the -x check fails and only in Jenkins. It is executable by the user and group -> gradle:1000:1000 - that comes with the image : gradle:7.4.2-jdk8
I would appreciate any insight to this issue. Thank you.
same issue with TeamCity agent. It runs docker-in-docker.
In container (DockerInDocker) test -x $JAVA_HOME/bin/java returns 1.
In agent test -x $JAVA_HOME/bin/java returns 0.
0777 mode, root owner as well.
Also seeing the same issue in Jenkins running on k8s. Using eclipse-temurin:11.0.15_10-jdk as the base image. Checking the Java executable before gradlew is called give me:
13:34:46 Step 9/23 : RUN ls -la /opt/java/openjdk/bin/java
13:34:46 ---> Running in d7a82558e4b2
13:34:47 -rwxr-xr-x 1 root root 12768 Apr 19 21:38 /opt/java/openjdk/bin/java
but when I test for executable perms I get:
13:24:57 Step 10/22 : RUN test -x $JAVA_HOME/bin/java
13:24:57 ---> Running in 20dd8d832464
13:24:57 The command '/bin/sh -c test -x $JAVA_HOME/bin/java' returned a non-zero code: 1
It looks like commands are being run as root as well:
13:19:06 Step 10/21 : RUN id -u -n
13:19:06 ---> Running in 1ea36050bc88
13:19:06 root
What makes it weirder is that I'm able to manually create the same Jenkins pod used for builds, exec in and clone the repo and build the Docker image successfully with no issues.
I am trying to fork this docker image so that if anything changes on the original it won't affect me.
I have forked the repo corresponding to that image to my own repo.
I have cloned the repo and am trying to build it:
docker build . -t davcal/gcc-cross-x86_64-elf
I am getting this error:
+ cd /usr/local/src
+ ./build-binutils.sh 2.31.1
/bin/sh: 1: ./build-binutils.sh: not found
The command '/bin/sh -c set -x && cd /usr/local/src && ./build-binutils.sh ${BINUTILS_VERSION} && ./build-gcc.sh ${GCC_VERSION}' returned a non-zero code: 127
What makes no sense to me is that if I use the original image, it builds successfully:
FROM randomdude/gcc-cross-x86_64-elf
...
Maybe Docker Hub stores a pre-built image?
How do I fix this?
Note: I am using Windows. This shouldn't make a difference since the error originates within the container.
Edit
I tried patching the Dockerfile to chmod executable permissions to the sh files in case that was causing problems on Windows. Unfortunately, the exact same error occurs.
RUN set -x \
&& chmod +x /usr/local/src/build-binutils.sh \
&& chmod +x /usr/local/src/build-gcc.sh \
&& cd /usr/local/src \
&& ./build-binutils.sh ${BINUTILS_VERSION} \
&& ./build-gcc.sh ${GCC_VERSION}
Edit 2
Following this method, I inspected the container to see if the sh files actually exist. Here is the output.
I ran docker run --rm -it c53693f11514 bash, including the hash of the intermediate container of the previous successful step of the Dockerfile.
This is the output showing that the files do exist:
root#9b8a64ac2090:/# cd usr/local/src
root#9b8a64ac2090:/usr/local/src# ls
binutils-2.31.1 build-binutils.sh build-gcc.sh gcc-8.2.0
From the described symptoms, file exists, is a shell script, and works on other machines, the "file not found" error is most likely from Winidows linefeeds being added to the file. When the Linux kernel processes a shell script, it looks at the first line, the #!/bin/sh or similar, and then finds that interpreter to run the shell script. If that interpreter isn't found, you'll get a "file not found" error.
In this case, the file it's looking for won't be /bin/sh, but instead /bin/sh\r or /bin/sh^M depending on how you want to represent the carriage return character. You can fix that for single files with a tool like dos2unix but in general, you'll want to fix git itself since there are likely other files that have had their linefeeds corrupted. For details on adjusting the behavior of git, see this post.
I have managed to install github cli in container but I am unable to run it as a random user (open shift does runs containers as random user due to security)
What directories should I create/chmod/chown beforehand to make it work?
THANK YOU!
docker file:
RUN wget https://github.com/cli/cli/releases/download/v1.0.0/gh_1.0.0_linux_amd64.deb
RUN dpkg -i gh_*_linux_amd64.deb
RUN chmod g+rwx -R /usr/local/bin/gh # <- not enough
RUN gh version
container log:
...
Step 7/28 : RUN gh version
---> Running in 09d1ffbfcc02
Welcome to GitHub CLI!
To authenticate, please run `gh auth login`.
You can also set the GITHUB_TOKEN environment variable, if preferred.
The command '/bin/sh -c gh version' returned a non-zero code: 4
`/` is not writable.
...
there is a bug in the docs, it is
gh --version
not
gh version
also RUN chmod g+rwx -R /usr/local/bin/ before mentioned command helps.
I have run docker run to generate a file
sudo docker run -i --mount type=bind,src=/home/mathed/Simulation/custom_desman/1/Strains/Simulation2/Assembly,target=/home/mathed/Simulation/custom_desman/1/Strains/Simulation2/Assembly 990210oliver/mycc.docker:v1 MyCC.py /home/mathed/Simulation/custom_desman/1/Strains/Simulation2/Assembly/final_contigs_c10K.fa
This is the message I've got after executing.
20181029_0753
4mer
1_rename.py /home/mathed/Simulation/custom_desman/1/Strains/Simulation2/Assembly/final_contigs_c10K.fa 1000
Seqs >= 1000 : 32551
Minimum contig lengh for first stage clustering: 1236
run Prodigal.
/opt/prodigal.linux -i My.fa -a gene.aa -d gene.nuc -f gbk -o output -s potential_genes.txt
run fetchMG.
run UCLUST.
Get Feature.
2_GetFeatures_4mer.py for fisrt stage clustering
2_GetFeatures_4mer.py for second stage clustering
3_GetMatrix.py 1236 for fisrt stage clustering
22896 contigs entering first stage clustering
Clustering...
1_bhsne.py 20
2_ap.py /opt/ap 500 0
Cluster Correction.
to Split and Merge.
1_ClusterCorrection_Split.py 40 2
2_ClusterCorrection_Merge.py 40
Get contig by cluster.
20181029_0811
I now want to get the files generated by MyCC.py to host.
After reading Copying files from Docker container to host, I tried,
sudo docker cp 642ef90103be:/opt /home/mathed/data
But I got an error message
mkdir /home/mathed/data/opt: permission denied
Is there a way to get the files generated to a directory /home/mathed/data?
Thank you.
I assume your dest path does not exist.
Docker cp doc stats that in that case :
SRC_PATH specifies a directory
DEST_PATH does not exist
DEST_PATH is created as a directory and the contents of the source directory are copied into this directory
Thus it is trying to create a directory fro DEST_PATH... and docker must have the rights to do so.
According to the owner of the DEST_PATH top existing directory, you may have to either
create the directory first so that it will not be created by docker and give it the correct rights (looks like it has no rights to do so) using sudo chown {user}:{folder} + chmod +x {folder}
change the rights to the parent existing directory (chown + chmod again),
switch to path where docker is allowed to write.
I have a very simple docker build file:
FROM openjdk:10
ENV JENAVERSION=3.7.0
RUN mkdir /fuseki
RUN wget http://apache.claz.org/jena/binaries/apache-jena-fuseki-$JENAVERSION.tar.gz -P /tmp \
&& tar -zxvf /tmp/apache-jena-fuseki-$JENAVERSION.tar.gz -C /tmp \
&& mv -v /tmp/apache-jena-fuseki-$JENAVERSION/* /fuseki
EXPOSE 3030
ENTRYPOINT ["/bin/bash", "/fuseki/fuseki-server"]
I've tried different variations on CMD and ENTRYPOINT, but nothing allows "fuseki-server" to execute. Always a "No such file or directory" error. If I manually create an empty container from openjdk:10, and execute each command manually, it works fine. What's going on?
I think the issue is the line ending - the entrypoint needs to have LF line ending.
I get the same error when my entrypoint has CLRF line ending.
If I build and run your Dockerfile, I get a different error from what you've described. I see:
Can't find jarfile to run
If you look at the fuseki-server shell script, it's trying to find the jar file relative either to your current directory or to the $FUSEKI_HOME environment variable:
export FUSEKI_HOME="${FUSEKI_HOME:-$PWD}"
if [ ! -e "$FUSEKI_HOME" ]
then
echo "$FUSEKI_HOME does not exist" 1>&2
exit 1
fi
JAR1="$FUSEKI_HOME/fuseki-server.jar"
JAR2="$FUSEKI_HOME/jena-fuseki-server-*.jar"
JAR=""
So if you set the FUSEKI_HOME environment variable in your
Dockerfile:
ENV FUSEKI_HOME=/fuseki
Then the container starts up without errors:
[2018-06-04 14:02:17] Server INFO Apache Jena Fuseki 3.7.0
[2018-06-04 14:02:17] Config INFO FUSEKI_HOME=/fuseki
[2018-06-04 14:02:17] Config INFO FUSEKI_BASE=/run
[2018-06-04 14:02:17] Config INFO Shiro file: file:///run/shiro.ini
[2018-06-04 14:02:18] Server INFO Started 2018/06/04 14:02:18 UTC on port 3030
Wow... After going through #larsk's suggestion it occurred to me to change the entrypoint to
ENTRYPOINT ["tail", "-f", "/dev/null"]
and go into the container to see what was actually there. It turns out that I was accidently overwriting the /fuseki folder with a volume declaration in the compose file I was using. (facepalm...)