You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose to have a unique source of truth for all image definitions (Linux and Windows), variables and helper functions.
Goals:
Avoid mistakes, oversights, inconsistencies or more work to do thanks to unique location of image definitions
Simplify build.ps1, which won't have to massage data for images definitions anymore
Pave the way for when we'll be able to use docker buildx bake to build and publish images on Windows
How?
Even if docker buildx bake can't be used for building images on Windows yet, it can already be used on Windows with the --print parameter, outputting Windows images definitions as a JSON.
This output can then be converted with yq (already required for building Windows images) into the format expected by docker compose, still used (for now) for building and publishing Windows images.
Avoid mistakes, oversights, inconsistencies or more work to do thanks to unique location of image definitions
Having only one place to store image definitions, build variables and helper functions would decrease the risk of mistakes or oversights, and reduce the work needed to change parameters common to both Linux and Windows, currently defined in two distinct files and a bit of data manipulations defined in build.ps1.
Ex: the work I've done for jenkinsci/docker#1891 to remove Java 11 from Weekly release line would have been much more simpler.
Something like that:
-variable "jdks_to_build" {- default = [11, 17, 21]+# Return the JDKs to build depending if the version matches LTS versionning pattern+function "jdkstobuild" {+ param = [version]+ # Return all JDKs only if the version matches LTS versionning pattern+ result = equal(regex(version, ltsRegexPattern), "") ? [17, 21] : [11, 17, 21]
}
target "alpine" {
matrix = {
- jdk = jdks_to_build+ jdk = jdkstobuild(VERSION)
}
target "debian" {
matrix = {
- jdk = jdks_to_build+ jdk = jdkstobuild(VERSION)
}
target "nanoserver" {
matrix = {
- jdk = jdks_to_build+ jdk = jdkstobuild(VERSION)
}
target "windowsservercore" {
matrix = {
- jdk = jdks_to_build+ jdk = jdkstobuild(VERSION)
}
Here is the code that would be required to remove Java 11 from Linux and Windows images here with the proposed enhancement:
Another place where it reduces complexity: the updatecli manifests, reducing the number of targets.
Implementing something like jenkinsci/docker-agent#816 would result in a new Dockerfile argument and a docker bake function returning the correct WINDOWS_VERSION_DIGEST depending on the Windows version, no blocker from the enhancement.
# Ensure constant env vars used in the docker compose file are defined
$env:DOCKERHUB_ORGANISATION="$Organisation"
$env:DOCKERHUB_REPO="$Repository"
$env:VERSION="$VersionTag"
$items=$ImageType.Split('-')
$env:WINDOWS_FLAVOR=$items[0]
$env:WINDOWS_VERSION_TAG=$items[1]
$env:TOOLS_WINDOWS_VERSION=$items[1]
if ($items[1] -eq'ltsc2019') {
# There are no eclipse-temurin:*-ltsc2019 or mcr.microsoft.com/powershell:*-ltsc2019 docker images unfortunately, only "1809" ones
$env:TOOLS_WINDOWS_VERSION='1809'
}
With this enhancement, build.ps1 would just be used for:
(new) Optionally setting up the docker compose file generation from the docker bake definition without having to work on them
Calling docker compose
Optionally setting up the tests harness and calling Pester to run it
Apart from this generation, the rest of the process is unchanged, just an additional init step to generate the docker compose file, optional if it already exists.
When docker buildx will be able to build images on Windows, build.ps1 role will be:
Calling docker buildx bake
Optionally setting up the tests harness and calling Pester to run it
Contributors will be able to either use build.ps1 to (re)generate their docker compose file, or a command line that will be explained in the README to generate themselves the docker compose file. (See "miscellaneous" below)
With this proposed change, build.ps1 isn't mandatory for contributors anymore, they will be able to build and publish their own images by using docker bake and docker compose only.
Pave the way for when we'll be able to use docker buildx bake to build and publish images on Windows
BuildKit seems to be able-ish to build images on Windows:
When it will be ready, we'll be able to remove the docker compose file generation and call and just use docker buildx bake to build and publish all images.
Miscellaneous
Example of the call to generate the docker compose file from a Windows machine:
What feature do you want to see added?
I propose to have a unique source of truth for all image definitions (Linux and Windows), variables and helper functions.
Goals:
docker buildx bake
to build and publish images on WindowsHow?
Even if
docker buildx bake
can't be used for building images on Windows yet, it can already be used on Windows with the--print
parameter, outputting Windows images definitions as a JSON.docker buildx bake windows --print
This output can then be converted with
yq
(already required for building Windows images) into the format expected by docker compose, still used (for now) for building and publishing Windows images.Corresponding docker compose file content
Current docker compose file content for comparison
Notice that almost all args currently have to be injected by build.ps1:
docker-ssh-agent/build-windows.yaml
Lines 1 to 39 in bad0642
Details
Avoid mistakes, oversights, inconsistencies or more work to do thanks to unique location of image definitions
Having only one place to store image definitions, build variables and helper functions would decrease the risk of mistakes or oversights, and reduce the work needed to change parameters common to both Linux and Windows, currently defined in two distinct files and a bit of data manipulations defined in build.ps1.
Ex: the work I've done for jenkinsci/docker#1891 to remove Java 11 from Weekly release line would have been much more simpler.
Something like that:
Here is the code that would be required to remove Java 11 from Linux and Windows images here with the proposed enhancement:
Another place where it reduces complexity: the updatecli manifests, reducing the number of targets.
Implementing something like jenkinsci/docker-agent#816 would result in a new Dockerfile argument and a docker bake function returning the correct WINDOWS_VERSION_DIGEST depending on the Windows version, no blocker from the enhancement.
Simplify build.ps1, which won't have to massage data for images definitions anymore
Currently, build.ps1 is used to massage the data for the image definitions and is in charge of the special case like this:
docker-ssh-agent/build.ps1
Lines 39 to 51 in bad0642
With this enhancement, build.ps1 would just be used for:
Apart from this generation, the rest of the process is unchanged, just an additional init step to generate the docker compose file, optional if it already exists.
When docker buildx will be able to build images on Windows, build.ps1 role will be:
Contributors will be able to either use build.ps1 to (re)generate their docker compose file, or a command line that will be explained in the README to generate themselves the docker compose file. (See "miscellaneous" below)
With this proposed change, build.ps1 isn't mandatory for contributors anymore, they will be able to build and publish their own images by using docker bake and docker compose only.
Pave the way for when we'll be able to use
docker buildx bake
to build and publish images on WindowsBuildKit seems to be able-ish to build images on Windows:
But docker buildx isn't yet.
Main issues to follow the progress:
When it will be ready, we'll be able to remove the docker compose file generation and call and just use docker buildx bake to build and publish all images.
Miscellaneous
Example of the call to generate the docker compose file from a Windows machine:
The only new requirements is docker buildx as docker, docker compose and yq are already required.
Corresponding change (missing the doc, incoming)
ed751ae
Working build locally and on ci.jenkins.io
https://ci.jenkins.io/job/Packaging/job/docker-ssh-agent/job/PR-415/88/
Upstream changes
No response
Are you interested in contributing this feature?
Yes:
The text was updated successfully, but these errors were encountered: