Skip to content

Cases where we infer the wrong path to the artifact #911

@algomaster99

Description

@algomaster99

I have roughly seen two types of cases why the artifact is not found even when the build succeeds.

Case I: version different

maven,com.google.j2objc:j2objc-annotations,3.0.0,j2objc-annotations-3.0.0.jar

Strategy
#syntax=docker/dockerfile:1.10
FROM docker.io/library/debian:trixie-20250203-slim
RUN <<'EOF'
 set -eux
 apt update
 apt install -y git wget maven
EOF
RUN <<'EOF'
 set -eux
 mkdir -p /src && cd /src
 git clone https://github.com/google/j2objc .
 git checkout --force 'cff004b845f94255bcb1863ac7cf822778357550'
 mkdir -p /opt/jdk
 wget -q -O - "https://download.java.net/java/ga/jdk11/openjdk-11_linux-x64_bin.tar.gz" | tar -xzf - --strip-components=1 -C /opt/jdk
EOF
RUN cat <<'EOF' >/build
 set -eux
 export JAVA_HOME=/opt/jdk
 export PATH=$JAVA_HOME/bin:$PATH
 mvn clean package -DskipTests --batch-mode -f annotations -Dmaven.javadoc.skip=true -Djdk.tls.client.protocols="TLSv1.2"
 chmod +444 /src/annotations/target/j2objc-annotations-3.0.0.jar
 mkdir -p /out && cp /src/annotations/target/j2objc-annotations-3.0.0.jar /out/
EOF
WORKDIR "/src"
ENTRYPOINT ["/bin/sh","/build"]

Inference logs suggest that we took selected the commit based on tag and did not verify the version.

using tag heuristic with mismatched version [expected=3.0.0,actual=3.0.0-SNAPSHOT,path=annotations/pom.xml,ref=cff004b84]

The version is the pom file should be changed to 3.0.0

the drawback here is that we may select a completely wrong version and still change the pom file.

  • document cases where we select commit even though the version in the pom file does not match

maven,org.tomlj:tomlj,1.1.1,tomlj-1.1.1.jar

Strategy
#syntax=docker/dockerfile:1.10
FROM docker.io/library/debian:trixie-20250203-slim
RUN <<'EOF'
 set -eux
 apt update
 apt install -y git wget
EOF
RUN <<'EOF'
 set -eux
 mkdir -p /src && cd /src
 git clone https://github.com/tomlj/tomlj .
 git checkout --force '954c3876ab92c88c17974a2bcb519c022df3fd6f'
 mkdir -p /opt/jdk
 wget -q -O - "https://github.com/adoptium/temurin11-binaries/releases/download/jdk-11.0.28%2B6/OpenJDK11U-jdk_x64_linux_hotspot_11.0.28_6.tar.gz" | tar -xzf - --strip-components=1 -C /opt/jdk
EOF
RUN cat <<'EOF' >/build
 set -eux
 export JAVA_HOME=/opt/jdk
 export PATH=$JAVA_HOME/bin:$PATH
 ./gradlew assemble --no-daemon --console=plain -Pversion=1.1.1
 chmod +444 /src/build/libs/tomlj-1.1.1.jar
 mkdir -p /out && cp /src/build/libs/tomlj-1.1.1.jar /out/
EOF
WORKDIR "/src"
ENTRYPOINT ["/bin/sh","/build"]

tomlj-1.1.1-dev.jar is generated despite explicity forcing version using -Pversion=1.1.1.

Another example is here. It seems that Gradle does not respect the version we set.

Case II: name different

maven,org.semver4j:semver4j,5.2.2,semver4j-5.2.2.jar

Strategy returned for this case

{
  "maven_build": {
    "repo": "https://github.com/semver4j/semver4j",
    "ref": "bf58e56af8be2aa1e67bcdb1e44c0ba3eb4aba79",
    "dir": ".",
    "jdk_version": "11"
  }
}

However, the version in pom.xml corresponding to this commit is 0.0.1-SNAPSHOT. So upon running mvn clean package -DskipTests --batch-mode -f . -Dmaven.javadoc.skip=true, the artifact produced is called semver.jar. Now this is independent of the version because the finalName in the pom file is set to be artifactId.

The expected artifact name can be guessed from <finalName> property

maven,org.java-websocket:Java-WebSocket,1.5.6,Java-WebSocket-1.5.6.jar

Strategy
#syntax=docker/dockerfile:1.10
FROM docker.io/library/debian:trixie-20250203-slim
RUN <<'EOF'
 set -eux
 apt update
 apt install -y git wget zip
EOF
RUN <<'EOF'
 set -eux
 mkdir -p /src && cd /src
 git clone https://github.com/tootallnate/java-websocket .
 git checkout --force 'ae78d38da8800fe79b19550d37b074eebd1bf965'
 mkdir -p /opt/jdk
 wget -q -O - "https://download.java.net/java/GA/jdk18/43f95e8614114aeaa8e8a5fcf20a682d/36/GPL/openjdk-18_linux-x64_bin.tar.gz" | tar -xzf - --strip-components=1 -C /opt/jdk
 wget -q -O tmp.zip https://services.gradle.org/distributions/gradle-8.14.3-bin.zip
 unzip -q tmp.zip -d /opt/ && mv /opt/gradle-8.14.3 /opt/gradle
 rm tmp.zip
EOF
RUN cat <<'EOF' >/build
 set -eux
 export JAVA_HOME=/opt/jdk
 export PATH=$JAVA_HOME/bin:$PATH
 export GRADLE_HOME=/opt/gradle
 export PATH=$GRADLE_HOME/bin:$PATH
 gradle assemble --no-daemon --console=plain -Pversion=1.5.6
 chmod +444 /src/build/libs/Java-WebSocket-1.5.6.jar
 mkdir -p /out && cp /src/build/libs/Java-WebSocket-1.5.6.jar /out/
EOF
WORKDIR "/src"
ENTRYPOINT ["/bin/sh","/build"]

This produces build/libs/src-1.5.6.jar which is completely different from what we expect Java-WebSocket-1.5.6.jar.

maven,com.github.spotbugs:spotbugs-annotations,4.8.6,spotbugs-annotations-4.8.6.jar

// To keep backward compatibility, delete version number from jar name

Some good news: To my surprise, we did not find a case where we guess the directory incorrectly (so far).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions