feat(linux): add HEALTHCHECK instruction

[amdadulbari]

Added HEALTHCHECK instruction to the alpine, debian, and rhel controller Dockerfiles to improve container orchestration and monitoring reliability. The healthcheck verifies that the Jenkins login page is accessible.

Testing done

Validated that the docker build command successfully parses the Dockerfiles with the new HEALTHCHECK instruction.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[MarkEWaite]

Please use the /health endpoint instead of /login. It was added in Jenkins 2.506. You can read more about the /health endpoint in issue:

• jenkinsci/jenkins#16702

Please test that the controller starts and runs as expected. Testing that docker build completes successfully is necessary, but not sufficient for this pull request.

[amdadulbari]

Please use the /health endpoint instead of /login. It was added in Jenkins 2.506. You can read more about the /health endpoint in issue:

• jenkinsci/jenkins#16702

Please test that the controller starts and runs as expected. Testing that docker build completes successfully is necessary, but not sufficient for this pull request.

Thank you for the feedback! I have updated the HEALTHCHECK instruction to use the /health endpoint as requested.

I have also verified that the controller starts up correctly and the health check works as expected.

Here is the verification summary:

Controller Startup:

• Confirmed logs show Jenkins is fully up and running.
• Health Check Status: docker inspect reports "Status": "healthy".
• Endpoint Response: curl http://localhost:8080/health returns 200 OK with {"status":true}.

The changes have been pushed.

[lemeurherve]

Is it possible to have this HEALTHCHECK in Windows images too?

Is it possible to put those HEALTHCHECKs more closer to the bottom of Dockerfiles?

[amdadulbari]

Is it possible to have this HEALTHCHECK in Windows images too?

Is it possible to put those HEALTHCHECKs more closer to the bottom of Dockerfiles?

As requested, I’ve moved the HEALTHCHECK instructions to the bottom of the Dockerfiles for the Linux images.
I’m keeping this PR scoped to the Linux variants for now, since I’m currently working on a non-Windows machine.

[amdadulbari]

@lemeurherve Thanks for the feedback. Updated accordingly.

[dduportal]

FTR, there has been discussion years ago about adding HEALTHCHECK in the Dockerfile vs. only documenting it.

This feature is not really portable:

• It does NOT work with other container engine or orchestrators than Docker CE (not on Podman, not on Kubernetes, etc.). Creating a feature which is "Docker-only" may create false expectations for end users. Hence the suggestion (which was never followed up years ago) to document the health check instead, with a docker-compose example
• Also, the healthcheck feature executes commands inside the container, eg. creates dependency on the binary used (here it is curl). What if curl is removed from the main image for instance?

[amdadulbari]

FTR, there has been discussion years ago about adding HEALTHCHECK in the Dockerfile vs. only documenting it.

This feature is not really portable:

• It does NOT work with other container engine or orchestrators than Docker CE (not on Podman, not on Kubernetes, etc.). Creating a feature which is "Docker-only" may create false expectations for end users. Hence the suggestion (which was never followed up years ago) to document the health check instead, with a docker-compose example

• Also, the healthcheck feature executes commands inside the container, eg. creates dependency on the binary used (here it is curl). What if curl is removed from the main image for instance?

This PR is intentionally Docker-scoped to improve the Docker-native experience (docker ps / docker inspect) and does not aim to define a portable or orchestrator-level health signal. While Docker-only, HEALTHCHECK is a well-established convention and provides immediate value for users running Jenkins directly with Docker.

Regarding the curl dependency: it’s lightweight, not part of Jenkins’ functional path, and if it’s ever removed the health check can be trivially adjusted without impact. I’m happy to add a short note clarifying these assumptions if needed.

[timja]

and if it’s ever removed the health check can be trivially adjusted without impact. I’m happy to add a short note clarifying these assumptions if needed.

How? Adding the dependency on curl here makes it harder to remove it.

[amdadulbari]

and if it’s ever removed the health check can be trivially adjusted without impact. I’m happy to add a short note clarifying these assumptions if needed.

How? Adding the dependency on curl here makes it harder to remove it.

To completely avoid the dependency on curl, I could implement a lightweight Java-based health check that relies solely on the JRE already present in the image. Would you prefer I switch to that approach?

[lemeurherve]

Still not really convinced.

Can you open an issue explaining in which context and why the Jenkins controller image would need this healthcheck requiring an additional dependency (IOW increasing maintainance burden) please?

Note: It's already configurable from the Jenkins helm chart:
https://github.com/search?q=repo%3Ajenkinsci%2Fhelm-charts%20health&type=code