IT-Tools

[Kubernetes]

Hi there,

I am working on packaging the IT-Tools App (Source: https://github.com/CorentinTh/it-tools ) to Cloudron.

It is a great Collection of handy online tools for developers, with great UX.

Best,
Michael

[Kubernetes]

It's done. The repository with the package can be found in Github (I was not able to create a new project in Cloudron Gitlab)

@staff Feel free to take the package over.

As this is my first time that I did a package (and also fork a project in general) I would be glad to get some feedback if I did it the right way, or if I did anything wrong.
Thanks

[Kubernetes]

I updated the package now to use the Cloudron Base Image and http server instead of nginx.
From my point of view it is now usable as a offical Cloudron App.

[timconsidine]

Well done !

I took a quick look at your latest repo and I see you have moved to replicating the contents of the original repo into yours.

I used to do this, and it certainly makes your Dockerfile easier in some ways.
But I think Cloudron devs prefer that your Dockerfile just pulls in a version (named or latest) from the source repo.
Apparently this simplifies the update process after it is adopted into the Cloudron store.

I think it would be worth considering an approach like one of the following.
They're 3 different but similar styles. Which is better depends on whether the source repo has published a release or not. YMMV as they say.
Not sure which would be better for IT-Tools.
[I've left the repo links in for purposes of illustration, but it's the Docker command format which is relevant.]

# Pull the IT-Tools application from the given repo
ADD https://github.com/CorentinTh/it-tools/archive/refs/heads/main.tar.gz /app/code
# Extract the application files and remove not required files
RUN tar -xzf main.tar.gz && rm main.tar.gz && mv it-tools-main/* . && rm -r it-tools-main

OR

RUN git clone --depth 1 --branch main https://github.com/mckaywrigley/chatbot-ui.git /app/code

OR

WORKDIR /app/code
RUN curl -sL https://github.com/nolanlawson/pinafore/archive/refs/tags/v2.2.0.tar.gz | tar --strip-components 1 -xvzf - && \ 
  yarn --production --pure-lockfile && \
  yarn build && \
  yarn cache clean && \
  rm -rf ./src ./docs ./tests ./bin

I'm far from an expert, just based on my experience to date.

[Kubernetes]

Your feedback is really appreciated, I will update the package.

[Kubernetes]

I updated the package now to fetch the github source and compile it.
From my point of view it is now usable as a offical Cloudron App

[timconsidine]

Looks nice and clean
Will try to take it for a run later

[timconsidine]

@Kubernetes said in IT-Tools:

I was not able to create a new project in Cloudron Gitlab

BTW, @nebulon or @girish or @????? can enable creating projects in Cloudron's Git
Not enabled as a default but can be on request.
But regular gitlab works fine (and maybe acts to spread the cloudron name a little bit)

[girish]

@Kubernetes did you register on our gitlab? If so, what is the user id?

[Kubernetes]

@girish It is User Id 5010

[girish]

@Kubernetes I have bumped your repo count.

[Kubernetes]

@girish Great, I will move the package projects from Github to Cloudron gitlab. Thank you.

[Kubernetes]

I have updated the Dockerfile to remove unrequired software and use of multi stage for build and production.

[girish]

@Kubernetes actually, it would be great if multi stage is removed as well. There is nothing wrong with it, but that we have 100s of apps already which don't use this and it's easier for us if things are consistent and helps us in terms of packaging time.

[Kubernetes]

@girish Not sure if I understand it right. Is the way to create the production build by multi staging wrong, or is something missing to remove the multi stage from production build? My assumption was that creating a multi staging build would benefit in smaller production image size? So you are asking if I could avoid multi staging in Dockerfile and build everyting directly on top of the Cloudron Base Image, right?

[timconsidine]

@Kubernetes sorry, my fault for suggesting multi-stage builds.
It was only because of the large image size.
But if you have been able to strip out some stuff, maybe that is just as effective.
I wasn't aware that Cloudron prefers single build images.

[Kubernetes]

@timconsidine no problem, it should be mentioned in the Cloudron Package Documentation. I learned a lot by using multi stage, so now I can roll back to single stage

[girish]

This is published now. Repo is at https://git.cloudron.io/cloudron/it-tools-app/

[Kubernetes]

@girish Great news, thanks for picking this up and publishing!

I see there are many differences to the initial work I have done and I will review them. But could you share with me some insights what I could have done better already in the first step, please? This may help to reduce overhead and/or work on your side for future packages?

[girish]

@Kubernetes yes, sorry, infact, I was just writing down the notes before you commented already.Obviously, we got inspired to get this package out because you showed how it can be done, so please keep going

• It was cloning git repo . This means that the entire git history is in the docker image
• It was not pinning the app to a specific version/release. We want to keep the docker builds to be reproducible (as much as we can). So, we pin the app to specific versions/releases.
• It had multi-stage , which was removed.
• Initially @vladimir-d also built the package from source but I found that the upstream project already provides release tarballs, so I switched it to just use that. In the long run, this means we don't need to track how the project is built (especially, people keep switching between npm/yarn/pnpm and all sorts of things these days ).
• http-server vs nginx - this doesn't matter. I think @vladimir-d just chose nginx because it's used in other projects.
• tests has the selenium tests. This is required for us to publish apps to the store. Let me know if you need any help running these. But can see that it installs an app and checks if it is running etc.