Usage: is "java -jar /usr/share/jenkins/agent.jar" up to date?

[boaks]

Describe your use-case which is not covered by existing documentation.

Using a debian image build with Dockerfile according the documented usage

docker run -i --rm --name agent --init jenkins/agent java -jar /usr/share/jenkins/agent.jar

results in

"-jar" is not a valid option
java -jar agent.jar [options...]
...

As far as I understand that Dockerfile

ENTRYPOINT ["/usr/local/bin/jenkins-agent"]

already starts the agent. And leaving out java -jar /usr/share/jenkins/agent.jar seems to "work on my machine".

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

usage

Are you interested in contributing to the documentation?

No response

[MarkEWaite]

I'm not able to duplicate the problem that you're describing. I ran the example command from the usage page as:

docker run -i --rm --name agent --init jenkins/agent java -jar /usr/share/jenkins/agent.jar

That started a Jenkins agent with the message

<===[JENKINS REMOTING CAPACITY]===>rO0ABXNy..."

The agent container is a building block for other containers like the inbound agent container.

Can you provide more details so that others can duplicate the issue?

[boaks]

I'm at tag: 3206.vb_15dcf73f6a_9-3, that contains the above cited Dockerfile in the folder debian.

I use

• Ubuntu 20-04,
• Docker Engine - Community Version: 20.10.10

As I wrote, the Dockerfile of that commit contains already an ENTRYPOINT in exec form. According Docker

Command line arguments to docker run will be appended after all elements in an exec form ENTRYPOINT

Therefore my conclusion was, that the error is caused by that Dockerfile ENTRYPOINT and simply obsoletes to provide these additional "docker cmd line arguments".

So, let me aslk, do you really use the Dockerfile of that tag?

Edit:
I guess, the issue is caused by the current development, the tag 4.13-2 uses the previous layout and may be not affected.

[hervelemeur]

I thing your confusion comes from the fact you're reading the agent readme, while the entrypoint you linked from the Dockerfile concerns the inbound agent, which is build from the same Dockerfile as another target.

[boaks]

Not sure, if there is confusion on my side.

As I wrote:
My understanding of the Dockerfile is in line with the docker documentation
My experience (just don't use the additional cmd line parameter) is in line with my understanding of docker.

Anyway, if you don't get this error, even if you build with the current dev Dockerfile, then it may be an issue on my side, which I was able to solve simply by inspecting the Dockerfile and act according the docker documentation.

[MarkEWaite]

I didn't need to build anything with the current dev Dockerfile because the container image is already published by hub.docker.com. I confirmed that the instructions for the published container image work as expected when I run:

docker run -i --rm --name agent --init jenkins/agent:3206.vb_15dcf73f6a_9-3-jdk21 java -jar /usr/share/jenkins/agent.jar

They also run as expected when I run

docker run -i --rm --name agent --init jenkins/agent java -jar /usr/share/jenkins/agent.jar

[boaks]

I didn't need to build anything with the current dev Dockerfile because the container image is already published by hub.docker.com.

Maybe you need to build it on your own to see the errors ;-).

[boaks]

That's the difference, if you build the container local from the current Dockerfile or pull it with "jenkins/agent:latest-bookworm-jdk17" from docker.

<             "Entrypoint": null,
---
>             "Entrypoint": [
>                 "/usr/local/bin/jenkins-agent"
>             ],

(first from docker, second form local build)

[MarkEWaite]

I built the container locally from the master branch plus one commit for #746. The way I built the containers locally was:

make build

I confirmed that there was a local container image and that local container image included:

jenkins/agent  latest-bookworm-jdk21            d301bcdd6805   14 minutes ago   295MB
jenkins/agent  latest-bookworm                  8122cdcf1e5e   14 minutes ago   283MB
jenkins/agent  latest-bookworm-jdk17            8122cdcf1e5e   14 minutes ago   283MB
jenkins/agent  latest-bookworm-jdk11            94589550c808   14 minutes ago   284MB

When I run one of those local container images with the command:

docker run -i --rm --name agent --init jenkins/agent:latest-bookworm-jdk17 java -jar /usr/share/jenkins/agent.jar

The output looks like this:

<===[JENKINS REMOTING CAPACITY]===>rO0AB...

Maybe you and I are building the container images differently?

[hervelemeur]

That's the difference, if you build the container local from the current Dockerfile or pull it with "jenkins/agent:latest-bookworm-jdk17" from docker.

<             "Entrypoint": null,
---
>             "Entrypoint": [
>                 "/usr/local/bin/jenkins-agent"
>             ],

(first from docker, second form local build)

What's the exact command you used to build your image?

Without specifying any target, docker build with result in an inbound agent image (the last target of the Dockerfile used to build both agent and inbound agent images).

To build the agent with docker build you must specify --target agent.

See also https://docs.docker.com/build/building/multi-stage/

[boaks]

Though I only need one agent for debian/jdk17, I run docker in the root folder with

docker build -t jenkins/agent:jdk17-debian -f debian/Dockerfile .

In my first comment I included a link to exactly that Dockerfile.
I guess I misinterpreted the commit message "feat: build both agent and inbound-agent images" as comment for that file ;-).

Sorry, and excuse my questions.

(Edit: using "--target agent" or, even better ;-), pull the container is the solution.)

[MarkEWaite]

Thanks for the clarification @boaks . The build process for this repository is of necessity more complicated than the typical build processes because we build for multiple platforms, multiple Java versions, and multiple output targets. We want to keep the common code in a single location and that has made the build of a single image more complicated.

The available configurations can be listed with make show. A single container can be build with make build-xxx where xxx is replaced with the image tag like agent_alpine_jdk11

[lemeurherve]

Sorry, and excuse my questions.

No worry, on the contrary thanks for opening this issue!

It underlines the fact that we should create a CONTRIBUTING or a HACKING documentation to clarify how to build the different images of this repository as since #570 it's a bit less simple and could be confusing.