@scooke
But about the original clone and build directory? Do I leave it, taking up space? Do I need it still?
You can delete it.
Buy if @nj decides to release an update you will have to clone it again, and build the update.
@BrutalBirdie Sure, I see that now. It was one of many assumed pieces of knowledge that I come across while trying to learn this stuff. It's assumed I will realize this is your server. One thing that definitely helped me misunderstand is the cloudron.dev bit... I initially thought that, ok, this is coming from cloudron somehow. Anyway, one hurdle hurdled. One good lesson learned. One detail I will be sure to highlight when I'm helping someone out.
Hmmmm I was thinking if I should do the example with placeholders so its more clear.
Next time placeholders will be used again to highlight the user needs to replace this part themself.
The second assumption was that I would know that the actual proper target
There is no 'proper' --target its your own decision how to name the target, I go with the id from the CloudronManifest.json.
like yours! (:0.0.1) or the BBB one (:1.0.20)
Because, again its your choice how the image is tagged.
cloudron build --help
Usage: cloudron build [options]
Build an app
Options:
--build-arg <namevalue> Build arg passed to docker. Can be used multiple times (default:
[])
--build-service-token <token> Build service token
-f, --file <dockerfile> Name of the Dockerfile
--set-repository [repository url] Change the repository
--set-build-service [buildservice url] Set build service app URL
--local Build docker images locally
--no-cache Do not use cache
--no-push Do not push built image to registry
--raw Raw output build log
--tag <docker image tag> Docker image tag. Note that this does not include the repository
name
-h, --help display help for command
The --tag option lets you chose a tag instead of the cryptic hash.
