Packaging own apps : what guidance do you want

[timconsidine]

Picking up on comments in other threads, I'm thinking to start a wiki that can provide some entry-level guidance.
This will not (must not) replace official packaging documents.
Rather it can be an entry to the official docs for those who read them and don't know how to start, plus tips examples etc.

So I'm curious :

• would that be helpful ?
• what topics would be helpful ?

[humptydumpty]

@timconsidine how hard would it be for someone like me to package an app if I don't know any programming languages?

What are the steps involved? How are the "connections" made? Is it similar to editing a config file where you enter the db name and pass, etc.? Do all apps involve the same packaging method considering apps can be built with different languages and tools (Go vs PHP, etc.)?

These are some questions that I can think of. As with anything new that I'm trying to learn, I'd like to see a video showing how it's done from A-Z with commentary going into detail on why they did it this way and if there are alternative methods (pros vs cons kinda thing).

[timconsidine]

@humptydumpty good suggestions !

[BrutalBirdie]

Some Ground Rules I made myself:

USE GIT!
Nothing is more frustrating then having a kinda working state, tinkering more, have a completely broken state again and then don't remember what changes you done.

/app/code - the application binary

Everything binary which shall not be changed and belongs to the application belongs in /app/code and can mostly be done in the Dockerfile.

If parts of the application require on premise files, like cache or temporary files which need to have read-write access it should go in either /tmp or /run (This can not be tested in the Dockerfile since it's at runtime).

/app/data - The userdata

Everything that is backup worthy belongs into /app/data for example a config file which the application uses with the users configuration.

Debugging and Testing

If something needs to be done while runtime it can be hard to debug?
Kinda.
If your first deployment of the app fails, don't run back into your editor and tinker around.
Put the app in recovery mode and then start the application in recovery mode to see which parts fail.

You can tinker around in recovery mode and try to get it working.
BUT! With each step you fix in recovery mode it will get harder to backtrace all the fixes you done.
Each fix should be noted down or coded in the start script for the application.
Don't run yourself into a rabbit hole with 10+ fixes and then restart the app to then lose all those fixes again.

Being Stuck

Don't worry, it's normal.
Take a break, get 5-10 Minutes of fresh air for each 1 Hour of coding.

Don't be afraid to ask questions.
If you are packaging an app you can create a forum post and 'blog' your progress and struggles.
There are many users here who will chime in and give useful advise.

A Copy-Cat is bad!
Really? No.
Take a look at other apps and how they got packaged.
Maybe a solution for your problem is in one of the other apps.
If something is working and can be reused, go for it.

[JLX89]

@timconsidine This would be awesome -- I've been putting it off due to time. But having a good getting started place would help out a lot!

• Getting Started Topics
• Tool Reference
• Cloudron Packaging

[timconsidine]

@BrutalBirdie good tips born from experience !

[JLX89]

Just thinking, also further information on enabling and implementing the private docker registry inside Cloudron would be huge!

[girish]

@timconsidine said in Packaging own apps : what guidance do you want:

This will not (must not) replace official packaging documents.

I think we will be more than happy to accept new guides/tutorial on this. You can either post it here and we can adapt it if you give us the permision. Alternately, can just submit a MR to https://git.cloudron.io/cloudron/docs

[scooke]

Something I would find useful is a per/language walk-though guide, using an existing, functioning Cloudron-polished App as an example. So, line by line/segment by segment (not sure if that is feasible), explain why this was organized/written the way it was. So, one for Nodejs, one PHP, although I guess the presence of DBs might complicate the one app per language approach.

[micmc]

@timconsidine Yes, as mentioned by @humptydumpty and maybe start with, what tools do I need to have ready, and we should get our feet wet with in some cases, before starting, which are going to be in use during the whole process.

• Cloudron CLI of course, what else?
• A docker registry?
• A GIT server?
• A VPS with docker installed?
• A Docker desktop version? (as well as the previous?)
• How are they connected?
• Etc

Maybe also an example of how one is (or should be) set up?

Thanks for the offer mate!