atomisthq / jibbit Goto Github PK

Is there a way to have multiple targets? Say one for when running locally and another that pushes to remote registry.

gradle/maven jib have a flag to allowInsecureRegistries which is useful in certain environments.

Can jibbit be made to support a similar config?

When jibbit is used from windows, the classpaths used in the image will have backslashes instead of slashes in the file paths. This yields the following error when the image is run:

Error: Could not find or load main class clojure.main
Caused by: java.lang.ClassNotFoundException: clojure.main

I believe that the problem is this line:

If I replace :from-working-dir there with :docker-path things work as expected.

I can provide a pull request if you'd like.

Github showing this repository as not having any branches. Is this intentional?

$ git ls-remote --heads https://github.com/atomisthq/jibbit.git

Last known commit appears to be from #20 (b052382)

This is a feature request for being able to add environment variables to the container (https://cloud.google.com/java/getting-started/jib#env-var).

I would imagine, that one could add them to the config in :env-vars or something like that.

I've attached a pull request that seems to add this feature.

Have been trying out jibbit and there are various strange behaviours

jibbit: 0.1.13
tools.build: 0.7.5

Does not work without :aot

• The docs indicate :aotis optional, but if I don't provide it, it fails with

Cannot invoke"java.nio.file.Path.getFileSystem()" because "path" is null (clojure-app-layers)

Class files are not included in the jar when using :aot

• Providing a main class with (:gen-class) and using the :aot flag, the app.jar in the resulting docker image does not have any class files
• this means running the docker image fails with

could not find or load main class <my.main.class>

I've spent time debugging the 2nd issue and it seems to be due to using tools.build 0.7.5, where src-dirs must be provided explicit as they are not inferred from the basis (aka paths in deps.edn). I can confirm that using tools.build 0.8.1 directly, the compile-clj function generates the class files correctly even without specifying src-dirs (which is how jibbit uses it).

Alternatively, allowing src-paths to be provided as an arg could work around it, though is a bit ugly.

In doing some work on the basis recently, I discovered that due to some sloppy coding on my part, the basis contained more data than it should have in the :resolve-args and :classpath-args keys.

In particular these code locations are pulling either :jvm-opts or :main-opts from the :classpath-args map. Neither of these are classpath args and were never expected to be data that should be there:

• https://github.com/atomisthq/jibbit/blob/main/src/jibbit/core.clj#L138
• https://github.com/atomisthq/jibbit/blob/main/src/jibbit/core.clj#L143
• https://github.com/atomisthq/jibbit/blob/main/src/jibbit/core.clj#L310

So, you should not be doing that. However, I do think it is reasonable to want those merged jvm-opts and main-opts and the basis now contains an official place to get that info in a new basis key :argmap.

To fix, update to at least tools.build 0.9.4, and replace :classpath-args with :argmap. The :classpath-args are deprecated and will be removed in the near future.

Hello,
First of all, thank you for the great work you are doing with jibbit! Very much appreciated!

Is there any way I can use an uberjar created by my tools.build program to create the container image? I am currently generating some custom files before building the uberjar and I would like to have those files in the JAR used to create the image.

Thank you!

Discussed on slack with @slimslenderslacks but thought I would raise an issue so its not forgotten.

If you use a code base in the polylith format the generated container is incomplete.

There is an example project here
https://github.com/furkan3ayraktar/clojure-polylith-realworld-example-app/tree/master/projects/realworld-backend

The cause of the issues is that polylith uses local/root and often relative paths so the components do not get picked up and included in the final build.

Hi!

My project uses non-default source and resource paths (created with command mkdir -p {dev,main,test}/{src,resources}) and it seems that when following instructions naïvely from the project README, the resulting layer has main/src and main/resources prefixes for the relevant files, instead of correct roots, which of course leads to non-existent main ns being loaded, a stacktrace and exit.

Can I provide my own JAR instead, and if so, what should the build script for it be? Eg. tools.build

Problem

In entry-point, the following is used for the entrypoint:

["java" "-Dclojure.main.report=stderr" "-Dfile.encoding=UTF-8"] and the -cp and -m args are concatenated to it.

It is common to start an app with custom JAVA_OPTS.

In the current implementation, the only way to do so seems to provide a custom entrypoint script such as:

java $JAVA_OPTS -cp ... clojure.main -m my.app.core

But providing the value of -cp is not ideal as it can be very long since jibbit does not provide a way to generate a uberjar.

Suggestion

In my case I would like entry-point to look like this for instance:

(defn entry-point
  [{:keys [basis aot jar-name main working-dir]}]
  (->> (concat
        ["java ${JAVA_OPTS} -Dclojure.main.report=stderr -Dfile.encoding=UTF-8"]
        (-> basis :argmap :jvm-opts)
        (if aot
          ["-jar" jar-name]
          (concat
           ["-cp" (container-cp basis working-dir) "clojure.main"]
           (if-let [main-opts (-> basis :argmap :main-opts)]
             main-opts
             ["-m" (pr-str main)]))))
       (interpose " ")
       (apply str)
       (conj ["sh" "-c"])))

Maybe the user could provide his own custom-entry-point in the jib config?

And in jib-build we could replace:

(.setEntrypoint (entry-point c))

by

(.setEntrypoint ((or (load-entry-point custom-entry-point) entry-point) c)) ;; with custom-entry-point the eventual custom fn provided in jib.edn for instance

Let me know if it makes sense.