Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OPENJDK-3676] WIP: convert installing some things over to artifacts: #559

Open
wants to merge 2 commits into
base: ubi10
Choose a base branch
from

Conversation

jmtd
Copy link
Member

@jmtd jmtd commented Feb 24, 2025

WIP WIP WIP

Depends upon #562 .

This would resolve https://issues.redhat.com/browse/OPENJDK-2814 and https://issues.redhat.com/browse/OPENJDK-3674


The pattern used in our containers for copying files in, up to now, was to do so entirely inside a script configure.sh, with the files to be copied in an adjacent directory artifacts, normally with a local directory heirarchy mirroring the destination in the image, e.g. modules/jdk/21/artifacts/opt/jboss/container/openjdk/jdk/jvm-options. The script usually changed the ownership and/or permissions of the files after copying them.

Cekit offers a different method, artifacts, which for some reason we overlooked using for this. Using this is normally shorter, by default sets the owner and group to root, and is more declarative, so makes the images easier to reason about. For the above example artifact, the diff to the configuration to copy it in would be

artifacts:
  - path: artifacts/opt/jboss/container/openjdk/jdk/jvm-options
    dest: /opt/jboss/container/openjdk/jdk

I've gone a step further in this PR and removed the deep directory heirarchies encoding the destination path, since that's now present in the YAML. Personally I find the deep directory heirarchies hard to work with.

Most of the configure.sh scripts have been removed, as all they did was the copying.

The copied files are all now owner by root:root, which I prefer, it was always weird to me that the scripts could theoretically be modified by the running web application.

Cekit artifacts handling does not change file permissions, so I've set the necessary permissions on the scripts in git itself.

@jmtd jmtd force-pushed the ubi10-test-artifacts branch 3 times, most recently from 05f7c2b to 4551ad0 Compare February 25, 2025 14:20
Copy link

@sefroberg sefroberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, after reading the artifacts doc I think I get it. I wonder if structuring the github repo to mimic the container image's structure might make this whole operation a lot more simple. Great progress though. For what you are attempting to do here, great improvements. Looks good to me.

The Maven provided in RHEL10 is Maven 3.9.

Signed-off-by: Jonathan Dowland <[email protected]>
@jmtd jmtd force-pushed the ubi10-test-artifacts branch from 60bf706 to 09ec0c4 Compare February 25, 2025 16:15
We currently move scripts into place by executing a configure.sh script,
and changing ownership and permissions etc. However, in the majority of
cases we could instead declare where scripts should be installed using
artifacts:. The advantages are: smaller sources; more declarative; more
uniform ownership (default root:root); no need to chown (set the
permissions on the script in git directly).

Also addresses OPENJDK-2814 (running user shouldn't own
/opt/jboss/container)

Signed-off-by: Jonathan Dowland <[email protected]>
@jmtd jmtd force-pushed the ubi10-test-artifacts branch from 09ec0c4 to 9b27cf4 Compare February 25, 2025 16:18
@jmtd jmtd changed the title WIP: convert installing some things over to artifacts: [OPENJDK-3676] WIP: convert installing some things over to artifacts: Feb 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants