IT-Tools
-
Your feedback is really appreciated, I will update the package.
-
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
-
Looks nice and clean
Will try to take it for a run later -
@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) -
@Kubernetes did you register on our gitlab? If so, what is the user id?
-
-
@Kubernetes I have bumped your repo count.
-
I have updated the Dockerfile to remove unrequired software and use of multi stage for build and production.
-
@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.
-
@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?
-
@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. -
@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
-
This is published now. Repo is at https://git.cloudron.io/cloudron/it-tools-app/
-
@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?
-
@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-servervsnginx- 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.
-
G girish marked this topic as a question on
-
G girish has marked this topic as solved on
