Fix BASE_IMAGE Issue and Optimise Docker Build Time to 8.3m with Precompilation #47

pascal082 · 2024-10-25T05:52:25Z

Fix BASE_IMAGE not working
Optimised Docker build time from 18m to 8.3m by precompiling MKL_jll and IntelOpenMP artifacts, resolving warnings and reducing startup load, and added gdal-bin, libgdal-dev, and libfftw3-dev for required geospatial and scientific dependencies

- Added explicit installation and precompilation of MKL_jll in the Dockerfile to resolve warnings about missing precompiled modules during container startup. - Precompiled MKL_jll and IntelOpenMP artifacts during the build phase, significantly reducing precompilation time from 18 minutes to 9 minutes by avoiding on-the-fly precompilation. - The time reduction is attributed to precompiling MKL_jll in advance, preventing the heavy processing load that would otherwise occur during runtime. - Added gdal-bin, libgdal-dev, and libfftw3-dev to the Dockerfile to support system dependencies required for geospatial and scientific computations.

ConnectedSystems · 2024-10-25T06:42:04Z

Dockerfile

 COPY ./Project.toml ./Project.toml
 COPY ./Manifest.toml ./Manifest.toml
-RUN julia --project=@reefguide -e 'using Pkg;  Pkg.instantiate(verbose=true)'
+# Pre-download and cache MKL_jll dependency before general precompilation
+RUN julia -e 'using Pkg; Pkg.add("MKL_jll"); Pkg.instantiate(); using MKL_jll'


Not sure which project is being instantiated here.

Am I correct in assuming the build is faster to complete because the step to precompile MKL and others is essentially skipped in subsequent builds?

Additionally, are the two copy statements above necessary? They seem to simply copy the current files to their current locations?

@ConnectedSystems Yes, subsequent builds are faster because the MKL_jll and other dependencies are precompiled and cached, which prevents the need for recompilation at runtime.

Regarding the COPY statements: yes, they are needed to ensure Project.toml and Manifest.toml are available for Julia to install and precompile dependencies during Pkg.instantiate()

Regarding the COPY statements: yes, they are needed to ensure Project.toml and Manifest.toml are available for Julia to install and precompile dependencies during Pkg.instantiate()

Yes, I'm asking for clarification as it looks like it is redundant (copy to same location?)

COPY ./here ./here

@ConnectedSystems No, it was not redundant. COPY ./Project.toml ./Project.toml transfers Project.toml from the local directory into the container, which is necessary for dependency setup. I have simplified this further by consolidating it into a single line: COPY Project.toml Manifest.toml ./.

Thanks for the clarification. Obviously I'm not so familiar with Docker

…opy commands

PeterBaker0 · 2024-10-27T22:08:56Z

Dockerfile

+COPY Project.toml Manifest.toml ./
+
+# Pre-download and cache MKL_jll dependency before general precompilation
+RUN julia -e 'using Pkg; Pkg.add("MKL_jll"); Pkg.instantiate(); using MKL_jll'


Correct me if I'm wrong - MKL_jll was already a dependency listed in Project/Manifest, right? So the only condition under which this would be faster is if a) the user has already fully built the project b) they go to build again and c) the Project.toml and Manifest.toml has not changed. In that situation, wouldn't the whole pre-compilation already be skipped since the cache would apply to these three layers anyway

COPY Project.toml Manifest.toml ./ # Pre-download and cache MKL_jll dependency before general precompilation RUN julia -e 'using Pkg; Pkg.add("MKL_jll"); Pkg.instantiate(); using MKL_jll' # Precompile Julia packages using BuildKit cache for better efficiency RUN julia --project=@reefguide -e 'using Pkg; Pkg.instantiate(); Pkg.precompile()'

I'm not against pulling out specific 'base' dependencies that we think the image should always have, however, there are some risks

what if the MKL_jll version changes - this is no longer tracked in the Project/Manifest, right?

why is this dependency special? Why not all the others? Is it just because it's slow?

If we do want to pull out a specific dependency, I think it makes more sense to do so before we copy the manifest files e.g. this order

RUN julia -e 'using Pkg; Pkg.add("MKL_jll"); Pkg.instantiate(); using MKL_jll' COPY Project.toml Manifest.toml ./ RUN julia --project=@reefguide -e 'using Pkg; Pkg.instantiate(); Pkg.precompile()'

This way, you would never need to pre-comp this layer again even if manifest/project change.

So in summary - I don't fully understand why this change actually reduces build times since a change in manifest/project will cause the whole thing to generally precompile again, and I have some concerns about adding hard coded dependencies which aren't version managed into the docker file.

yes, I'm confused by this too. All dependencies should be defined by Project.toml

@PeterBaker0
Correct me if I'm wrong - MKL_jll was already a dependency listed in Project/Manifest, right? So ..........

MKL_jll is included through dependencies like LinearAlgebra in Project.toml, meaning it will be precompiled during Pkg.instantiate() and Pkg.precompile(). Docker caching will indeed optimise repeat builds when Project.toml and Manifest.toml remain unchanged by reusing layers and skipping full re-precompilation.

The explicit precompilation of MKL_jll primarily benefits initial build times and mitigates startup warnings. By precompiling MKL_jll separately, we handle its specific overhead upfront, reducing runtime costs and potential resource bottlenecks during the first build. However, in subsequent cached builds, this layer’s impact is minimized as Docker caching will efficiently skip redundant precompilations when dependencies haven’t changed.

If we do want to pull out a specific dependency, I think it makes more sense to do so before we copy the manifest files

We need MKL_jll to be installed with the exact version specified in Manifest.toml, so it’s important to copy both Project.toml and Manifest.toml files first. With this approach, even if Project.toml or Manifest.toml changes and triggers a full re-precompile, Docker will maintain a separate layer for MKL_jll. This separate layer can streamline subsequent builds, as MKL_jll will already be precompiled and cached independently of the other dependencies. This optimises for scenarios where MKL_jll remains unchanged while other dependencies are updated.

what if the MKL_jll version changes - this is no longer tracked in the Project/Manifest, right?
Again, I can see from the Manifest.toml file that LinearAlgebra is configured to use MKL. If this is not essential, we could switch to using OpenBLAS instead. By running this after copying the Manifest.toml file, we ensure that the version specified in Manifest.toml is used. I have removed Pkg.add to prevent it from pulling a different version, ensuring the version from Manifest.toml is used.

why is this dependency special? Why not all the others? Is it just because it's slow?

MKL_jll is singled out because it is a large and resource-intensive dependency with a known tendency to cause significant build-time delays and runtime warnings if not precompiled. By precompiling MKL_jll explicitly during the Docker build phase, the process prevents these warnings and reduces the load at runtime. Other dependencies, generally less demanding, don’t typically require this upfront handling, which is why they aren't singled out in the same way.

@PeterBaker0 Correct me if I'm wrong - MKL_jll was already a dependency listed in Project/Manifest, right? So ..........

MKL_jll is included through dependencies like LinearAlgebra in Project.toml, meaning it will be precompiled during Pkg.instantiate() and Pkg.precompile(). Docker caching will indeed optimise repeat builds when Project.toml and Manifest.toml remain unchanged by reusing layers and skipping full re-precompilation.

The explicit precompilation of MKL_jll primarily benefits initial build times and mitigates startup warnings. By precompiling MKL_jll separately, we handle its specific overhead upfront, reducing runtime costs and potential resource bottlenecks during the first build. However, in subsequent cached builds, this layer’s impact is minimized as Docker caching will efficiently skip redundant precompilations when dependencies haven’t changed.

What do you mean by "initial build times" - why would initial build times be reduced? You're not actually doing less in the build, right?

"reducing runtime costs" - what runtime costs? Isn't this about decreasing build time? Are you saying the server starts faster?

"efficiently skip redundant precompilations when dependencies haven’t changed." I still don't understand why this is any different than how it was before? If the dependencies didn't change, then it would never have re-precompiled, right?

If we do want to pull out a specific dependency, I think it makes more sense to do so before we copy the manifest files

We need MKL_jll to be installed with the exact version specified in Manifest.toml, so it’s important to copy both Project.toml and Manifest.toml files first. With this approach, even if Project.toml or Manifest.toml changes and triggers a full re-precompile, Docker will maintain a separate layer for MKL_jll. This separate layer can streamline subsequent builds, as MKL_jll will already be precompiled and cached independently of the other dependencies. This optimises for scenarios where MKL_jll remains unchanged while other dependencies are updated.

I just don't think this is true. Docker cache layers will always be invalidated if the file hash of copied inputs changes. E.g.

user adds package

manifest file etc change

this invalidates the copy layer and all layers below it

MKL_jll layer needs to rebuild because step 3 invalidated this layer

other packages need to rebuild

what if the MKL_jll version changes - this is no longer tracked in the Project/Manifest, right? Again, I can see from the Manifest.toml file that LinearAlgebra is configured to use MKL. If this is not essential, we could switch to using OpenBLAS instead. By running this after copying the Manifest.toml file, we ensure that the version specified in Manifest.toml is used. I have removed Pkg.add to prevent it from pulling a different version, ensuring the version from Manifest.toml is used.

Sure - but then you will need to recompile MKL_jll anytime the Manifest or Project toml files change, which removes the benefit of pulling it out separately anyway?

why is this dependency special? Why not all the others? Is it just because it's slow?

MKL_jll is singled out because it is a large and resource-intensive dependency with a known tendency to cause significant build-time delays and runtime warnings if not precompiled. By precompiling MKL_jll explicitly during the Docker build phase, the process prevents these warnings and reduces the load at runtime. Other dependencies, generally less demanding, don’t typically require this upfront handling, which is why they aren't singled out in the same way.

Sure - but you would need to pin this version into the dockerfile itself and build it before you bring in project/manifest toml.

My thoughts:

If MKL_jll does indeed contribute significantly to build times, then there would be benefit to precompiling it separately.

Unlike other approaches, say conda in Python, where a separate copy of the package is installed for each environment, Julia will share packages that are previously installed across environments so long as the versions align.

This would be beneficial in the case that the version installed by this line:

RUN julia -e 'using Pkg; Pkg.add("MKL_jll"); Pkg.instantiate(); using MKL_jll'

is indeed compatible with the version specified in the Project.toml and Manifest.toml files, as installation/compilation is effectively skipped given the previously installed package can be used instead.

But as soon as there is version misalignment (the line above initially installing an older version, and the ReefGuideAPI.jl package specifying a newer version), then everything needs to be re-compiled. But subsequent builds after this will be "fast" again.

In the case the Project.toml file changes, but does not affect the MKL_jll dependency, then we would still get the improved build times.

I think we need some way of running the line above again if/when the version of MKL_jll in the Project.toml file changes, otherwise it'll just silently keep building slowly...

Does this make sense?

That's not how Docker cache works (from my understanding).

Layer cache hash := hash(file system hash at start of layer, build command and files referenced in the build command)

If the project/manifest change at all, even just a new line or an extra whitespace, this hash is now different (since the build command/referenced files has changed). This will always invalidate all following layers.

So afaik this "In the case the Project.toml file changes, but does not affect the MKL_jll dependency, then we would still get the improved build times." is not true.

But I talked with @pascal082 and I am going to validate this is the case.

I'm not unconvinced that the build times improved, just trying to understand why.

Just confirming that the above explanation matches tested behaviour i.e. any change to dependencies (Manifest/Project files) results in the entire build occurring again including MKL_jll

arlowhite · 2024-10-27T22:50:02Z

Dockerfile

@@ -1,5 +1,5 @@
 # See https://hub.docker.com/_/julia for valid versions.
-ARG JULIA_VERSION="1.10.5"
+ARG JULIA_VERSION="1.11.1"


Do we want to do 1.11 so it's always latest minor, or use exact versions?

@arlowhite It’s best to always confirm and specify the exact version you need.

Not always @pascal082 - particularly as a default. I think 1.11 is fine as well. If a user needs to specify an exact version they can always override the build arg.

If you run npm i <package> the default is ^x.y.z, which allows for patch version increments, for example.

I think v1.11 is fine too

…nd cache it before main package precompilation.

arlowhite · 2024-10-28T06:22:11Z

Dockerfile

-COPY ./Project.toml ./Project.toml
-COPY ./Manifest.toml ./Manifest.toml
-RUN julia --project=@reefguide -e 'using Pkg;  Pkg.instantiate(verbose=true)'
+COPY Project.toml Manifest.toml ./


For Julia 1.11, it should be Manifest-v1.11.toml

arlowhite · 2024-10-28T06:23:39Z

Dockerfile

+COPY Project.toml Manifest.toml ./
+
+# Pre-download and cache MKL_jll dependency before general precompilation
+RUN julia -e 'using Pkg; pkg_path = Pkg.TOML.parsefile("Manifest.toml")["packages"]["MKL_jll"]["git-tree-sha1"]; Pkg.develop(PackageSpec(name="MKL_jll", version=pkg_path)); Pkg.precompile()'


ERROR: KeyError: key "packages" not found

I get this too

PeterBaker0 · 2024-10-28T21:11:47Z

@pascal082 Given the above discussion - I think the following

changes to Julia version/build arg make sense with above comments
pulling out MKL_jll - it's not clear to me under what conditions this results in the reduced build times, are you referring to in the GitHub build pipeline, or your local machine? And what is the before/after - are these builds from scratch, or builds with a cache/partial cache? This is a bit of a variation from the norm in terms of building with dependencies so warrants an understanding of why this is saving time.

pascal082 · 2024-10-28T22:19:37Z

@pascal082 Given the above discussion - I think the following

changes to Julia version/build arg make sense with above comments

pulling out MKL_jll - it's not clear to me under what conditions this results in the reduced build times, are you referring to in the GitHub build pipeline, or your local machine? And what is the before/after - are these builds from scratch, or builds with a cache/partial cache? This is a bit of a variation from the norm in terms of building with dependencies so warrants an understanding of why this is saving time.

@PeterBaker0
Just returning to this. I think the team initially set up is the ideal scenario: having the benefits of a pinned default version while allowing flexibility to test or move to newer versions as needed with the build command. I can adjust it to always pull the latest version in the Dockerfile, which can then be overridden with the build command, if that aligns with the team’s standard - @arlowhite

Regarding MKL: I believe what's happening is that by pre-installing MKL_jll, dependent packages like FFTW and LinearAlgebra recognize it immediately, skipping redundant configuration steps. This results in faster build times and fewer re-compilations. See the screenshot showing compile times for packages using MKL -pre install/not. This improvement is related to changes in Julia 1.11 affecting package compilation .

@arlowhite and @PeterBaker0 Also, since there will be different versions, could we name the Manifest.toml file following a version-specific naming convention? For example, for version 1.11.1, it could be named Manifest-1.11.1.toml, allowing the Dockerfile to select the appropriate version automatically.

With MKL pre install

Without MKL pre install

Seeing if this resolves horrendous build times

arlowhite · 2024-10-28T23:49:27Z

In your MKL comparison, those look like different log sections. First in "Installed", second has time in ms, I'd assume precompile time.

ConnectedSystems · 2024-10-28T23:52:37Z

In discussion with @PeterBaker0 I've pushed an updated Project/Manifest file which explicitly specifies MKL_jll.

The thinking is that it will help the dependency resolver optimise the precompile order to avoid method invalidations.

Could someone test a build with this?

… cache for base MKL dep Signed-off-by: Peter Baker <[email protected]>

Signed-off-by: Peter Baker <[email protected]>

…scal

Signed-off-by: Peter Baker <[email protected]>

…scal

PeterBaker0 · 2024-10-29T01:18:34Z

In discussion with @PeterBaker0 I've pushed an updated Project/Manifest file which explicitly specifies MKL_jll.

The thinking is that it will help the dependency resolver optimise the precompile order to avoid method invalidations.

Could someone test a build with this?

Doesn't help unfortunately.

PeterBaker0 · 2024-10-29T01:21:51Z

@arlowhite @pascal082 I've pushed a revised workflow which pulls out the process of extracting the MKL_jll version into a separate script. I've also put some workflows which check this dependency is up to date, including before running a docker build.

The benefit of this approach is that the Dockerfile can now reference this dependency file before copying in the Manifest/Project files, so we don't need to rebuild MKL_jll any time the project dependencies change.

I tested these scenarios

7m48.721

install MKL
install everything

Vs

13m48.615s

install everything

And indeed @pascal082 's observation is correct that it does reduce build time very significantly.

With the latest approach, things seem even better (though probably within margin of error for system performance), last build was 5m38.439s.

@pascal082 you should take a look and make sure changes make sense.

Signed-off-by: Peter Baker <[email protected]>

pascal082 · 2024-10-29T02:22:39Z

@PeterBaker0 The remaining issue is ensuring we use the appropriate Manifest.toml file (in get_mkl.sh) that matches the Julia version we are working with

get_mkl.sh

Check if Manifest.toml exists

if [ ! -f "Manifest.toml" ]; then
echo "Error: Manifest.toml not found in current directory"
exit 1
fi

ConnectedSystems · 2024-10-29T04:21:20Z

.github/workflows/CheckMklDep.yml

+      - name: Extract current MKL hash from Manifest
+        id: extract
+        run: |
+          CURRENT_HASH=$(awk '/\[\[deps\.MKL_jll\]\]/{flag=1;next}/\[\[/{if(flag){exit}}flag&&/uuid/{gsub(/^.*= "|".*$/,"",$0);printf "%s", $0}' Manifest.toml)


I'm okay with this to be pragmatic, but noting in future we should aim to remove awkward use of awk.
Could we at least add a comment explaining what this magic line does?

arlowhite · 2024-10-29T05:25:24Z

I don't like all of this complexity escaping the Dockerfile. This works:

COPY Project.toml Manifest*.toml ./

# Compile MKL_jll first - this improves build time significantly - unsure exactly why
# Extract version from Pkg.status output
# Status `~/foo/Project.toml`
#  [856f044c] MKL_jll v2024.2.0+0
# +0 causes 'ERROR: ArgumentError: invalid base 10 digit '+' in "0+0"'
# sed regex is weird, couldn't get it to trim the '+', so using cut
RUN export MKL_JLL_VERSION=`julia --project=. -e 'using Pkg; Pkg.status("MKL_jll")' | sed -rn 's/.*MKL_jll v()/\1/p' | cut -d '+' -f 1` && \
  julia -e 'using Pkg; Pkg.add(name="MKL_jll", version=ENV["MKL_JLL_VERSION"]); Pkg.precompile()'

# Precompile Julia packages using BuildKit cache for better efficiency
RUN julia --project=@reefguide -e 'using Pkg; Pkg.instantiate(); Pkg.precompile()'

Also, the "hash" is a project/package UUID, it never changes. version is what specifies the MKL_jll version. We could use uuid if we're paranoid about "MKL_jll" name collision, but I don't think it's necessary.

EDIT: problem here is it requires moving the manifest copy above, which will invalidate the cache more often.

ConnectedSystems · 2024-10-29T20:02:31Z

Very zen Arlo, I prefer this approach.

…ndnecy Signed-off-by: Peter Baker <[email protected]>

Signed-off-by: Peter Baker <[email protected]>

PeterBaker0 · 2024-10-30T01:24:55Z

@arlowhite @ConnectedSystems @pascal082 have simplified the approach using combination of methods mentioned in conversations. Removed all github actions to sync mkl.dep as it was not worth complexity for meagre optimisations which are not relevant to github actions anyway.

See https://github.com/open-AIMS/ReefGuideAPI.jl/actions/runs/11585249026 for test build running now.

PeterBaker0 · 2024-10-30T01:26:02Z

@PeterBaker0 The remaining issue is ensuring we use the appropriate Manifest.toml file (in get_mkl.sh) that matches the Julia version we are working with

get_mkl.sh

Check if Manifest.toml exists

if [ ! -f "Manifest.toml" ]; then echo "Error: Manifest.toml not found in current directory" exit 1 fi

@pascal082 this is resolved now - have added Manifest* instead of Manifest to docker copy, and the above script no longer exists

arlowhite · 2024-11-11T22:57:34Z

Project.toml

@@ -28,6 +28,7 @@ JSON = "682c06a0-de6a-54ab-a142-c8b1cf79cde6"
 JSONWebTokens = "9b8beb19-0777-58c6-920b-28f749fee4d3"
 LibGEOS = "a90b1aa1-3769-5649-ba7e-abc5a9d163eb"
 LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"
+MKL_jll = "856f044c-d86e-5d09-b602-aeab76dc8ba7"


maybe more correct to put in weakdeps, but not sure if it affects how Julia operates

Pascal Omondiagbe added 2 commits October 21, 2024 12:13

Fix BASE_IMAGE not working #35

443c214

pascal082 requested review from arlowhite and PeterBaker0 October 25, 2024 05:52

pascal082 changed the title ~~Pascal~~ Fix BASE_IMAGE Issue and Optimise Docker Build Time to 8.3m with Precompilation Oct 25, 2024

ConnectedSystems reviewed Oct 25, 2024

View reviewed changes

Simplify Dockerfile by consolidating Project.toml and Manifest.toml c…

616f22f

…opy commands

PeterBaker0 reviewed Oct 27, 2024

View reviewed changes

arlowhite reviewed Oct 27, 2024

View reviewed changes

Added step to pre-download MKL_jll using version from Manifest.toml a…

2dbcf9d

…nd cache it before main package precompilation.

arlowhite reviewed Oct 28, 2024

View reviewed changes

Add explicit MKL_jll dependency

4750170

Seeing if this resolves horrendous build times

PeterBaker0 and others added 13 commits October 29, 2024 11:38

Trying out approach to derive dep separately so we can not invalidate…

8c3bd92

… cache for base MKL dep Signed-off-by: Peter Baker <[email protected]>

Broadening PR trigger

b564b49

Signed-off-by: Peter Baker <[email protected]>

Trying to trigger

b1e40a6

Signed-off-by: Peter Baker <[email protected]>

INtentional issue

9f5df24

Signed-off-by: Peter Baker <[email protected]>

Get rid of file specific triggers

a80f8f4

Signed-off-by: Peter Baker <[email protected]>

Trying to get action to trigger

33b3069

Signed-off-by: Peter Baker <[email protected]>

Really force trigger

8e26683

Signed-off-by: Peter Baker <[email protected]>

Default true

674e5e5

Signed-off-by: Peter Baker <[email protected]>

More info

5eee945

Signed-off-by: Peter Baker <[email protected]>

Comparison fix

8748f89

Signed-off-by: Peter Baker <[email protected]>

Different inputs

a79eb5f

Signed-off-by: Peter Baker <[email protected]>

Update MKL_jll.dep to match Manifest.toml

659b352

Test out publish workflow

de5713a

Signed-off-by: Peter Baker <[email protected]>

PeterBaker0 and others added 6 commits October 29, 2024 11:59

Merge branch 'pascal' of github.com:open-AIMS/ReefGuideAPI.jl into pa…

460c1ad

…scal

Permissions fix

385ebd3

Signed-off-by: Peter Baker <[email protected]>

Fixing the lookup to get uuid

7705e99

Signed-off-by: Peter Baker <[email protected]>

Update MKL_jll.dep to match Manifest.toml

3277242

Fix uuid

5216369

Signed-off-by: Peter Baker <[email protected]>

Merge branch 'pascal' of github.com:open-AIMS/ReefGuideAPI.jl into pa…

23f04fd

…scal

PeterBaker0 added 2 commits October 29, 2024 12:24

Remove push trigger

116100f

Signed-off-by: Peter Baker <[email protected]>

Merge branch 'main' into pascal

3fc7065

Signed-off-by: Peter Baker <[email protected]>

ConnectedSystems reviewed Oct 29, 2024

View reviewed changes

PeterBaker0 added 3 commits October 30, 2024 12:23

Removing github sync, slightly de-optimised but simpler, use pkg depe…

454f01d

…ndnecy Signed-off-by: Peter Baker <[email protected]>

Force test build

a9bfcc8

Signed-off-by: Peter Baker <[email protected]>

remove test build

8edafbb

Signed-off-by: Peter Baker <[email protected]>

PeterBaker0 requested a review from arlowhite October 30, 2024 01:24

arlowhite reviewed Nov 11, 2024

View reviewed changes

arlowhite approved these changes Nov 11, 2024

View reviewed changes

arlowhite merged commit adf7ddc into main Nov 11, 2024
1 check passed

ConnectedSystems deleted the pascal branch November 11, 2024 23:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix BASE_IMAGE Issue and Optimise Docker Build Time to 8.3m with Precompilation #47

Fix BASE_IMAGE Issue and Optimise Docker Build Time to 8.3m with Precompilation #47

pascal082 commented Oct 25, 2024 •

edited

Loading

ConnectedSystems Oct 25, 2024 •

edited

Loading

pascal082 Oct 25, 2024

ConnectedSystems Oct 25, 2024

pascal082 Oct 25, 2024

ConnectedSystems Oct 25, 2024

PeterBaker0 Oct 27, 2024

arlowhite Oct 27, 2024

pascal082 Oct 28, 2024

PeterBaker0 Oct 28, 2024

ConnectedSystems Oct 28, 2024 •

edited

Loading

PeterBaker0 Oct 28, 2024

PeterBaker0 Oct 28, 2024

arlowhite Oct 27, 2024

pascal082 Oct 28, 2024

PeterBaker0 Oct 28, 2024 •

edited

Loading

ConnectedSystems Oct 28, 2024 •

edited

Loading

arlowhite Oct 28, 2024

arlowhite Oct 28, 2024

PeterBaker0 Oct 28, 2024

PeterBaker0 commented Oct 28, 2024

pascal082 commented Oct 28, 2024 •

edited

Loading

arlowhite commented Oct 28, 2024

ConnectedSystems commented Oct 28, 2024

PeterBaker0 commented Oct 29, 2024

PeterBaker0 commented Oct 29, 2024

pascal082 commented Oct 29, 2024 •

edited

Loading

ConnectedSystems Oct 29, 2024

arlowhite commented Oct 29, 2024 •

edited

Loading

ConnectedSystems commented Oct 29, 2024 •

edited

Loading

PeterBaker0 commented Oct 30, 2024

PeterBaker0 commented Oct 30, 2024

Check if Manifest.toml exists

arlowhite Nov 11, 2024

Fix BASE_IMAGE Issue and Optimise Docker Build Time to 8.3m with Precompilation #47

Fix BASE_IMAGE Issue and Optimise Docker Build Time to 8.3m with Precompilation #47

Conversation

pascal082 commented Oct 25, 2024 • edited Loading

ConnectedSystems Oct 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ConnectedSystems Oct 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PeterBaker0 Oct 28, 2024 • edited Loading

Choose a reason for hiding this comment

ConnectedSystems Oct 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PeterBaker0 commented Oct 28, 2024

pascal082 commented Oct 28, 2024 • edited Loading

arlowhite commented Oct 28, 2024

ConnectedSystems commented Oct 28, 2024

PeterBaker0 commented Oct 29, 2024

PeterBaker0 commented Oct 29, 2024

pascal082 commented Oct 29, 2024 • edited Loading

Check if Manifest.toml exists

Choose a reason for hiding this comment

arlowhite commented Oct 29, 2024 • edited Loading

ConnectedSystems commented Oct 29, 2024 • edited Loading

PeterBaker0 commented Oct 30, 2024

PeterBaker0 commented Oct 30, 2024

Check if Manifest.toml exists

Choose a reason for hiding this comment

pascal082 commented Oct 25, 2024 •

edited

Loading

ConnectedSystems Oct 25, 2024 •

edited

Loading

ConnectedSystems Oct 28, 2024 •

edited

Loading

PeterBaker0 Oct 28, 2024 •

edited

Loading

ConnectedSystems Oct 28, 2024 •

edited

Loading

pascal082 commented Oct 28, 2024 •

edited

Loading

pascal082 commented Oct 29, 2024 •

edited

Loading

arlowhite commented Oct 29, 2024 •

edited

Loading

ConnectedSystems commented Oct 29, 2024 •

edited

Loading