AppDev
Cloudron App Packagers
Posts
-
Update on community packages -
Update on community packages@girish I absolutely love this idea but is there a way to maybe host a community store? Like Arch's AUR for example that way it can be searchable too - you can allow "verified devs" for an extra layer of security or something
-
CCAI : Cloudron Custom App Installer@LoudLemur thank you
- the tokens : this kinda reflects the "journey" that CCAI went on. Initially it was browser-only ... and not user's site. I acknowledge users' cautions about this. Hence recommending a short-lived token disposable for use in CCAI open browser
Then we had CCAI-P deployed on your own cloudron, and interacting with your own Cloudron. In this case a multi-use long-life token was OK and so recommended. I think the quote you included in your question is from CCAI-P.
Then CustomAppGateway got rid of browsers completely for initial install and you enter a token into the binary on your local device. So not needed to use single-use short-term token. But hey everyone's paranoid these days so no harm in doing so.
I don't recognise the need for a 3rd token, but it might an academic question, as Cloudron 9.1 will make all this redundant. A much smoother and less problematic security approach, because it's all "on platform"
-
RO vs RW : it needs to make changes to your Cloudron, so RW.
-
pretty icons : that all comes down to the app being deployed. CCAI-P uses a similar but deliberately different logo to Cloudron.
Let me know which apps are not rendering a nice icon, and I can look at it.
Cloudron :
CCAI / CCAI-P :
-
Funkwhale - A modern, convivial and free music serverFunkwhale now on CustomAppGateway, alongside Indiekit
-
Indiekit for Cloudron - IndieWeb Publishing ServerFunkwhale and Indict on CustomAppGateway
-
Update on community packages@timconsidine said in Update on community packages:
So, making sure I understand it correctly, for a CustomApp, the packager really just needs to add CloudronVersions.json to their repo (in addition to CloudronManifest.json, Dockerfile etc.) ? Neat !
Yes, correct.
cloudron versions addsimply creates CloudronVersions.json with the current manifest and current build information. Hopefully, it's all as obvious as I am making it sound
From the installation point of view, the repo can be closed, docker image can be private. Only the CloudronVersions.json has to be public.
I have added two new fields on the manifest - packagerName and packagerUrl.
Going forward, the icon in manifest will be deprecated. We will use iconUrl instead.
You said in a separate post you would defer the question of a catalogue of custom apps : is that still the thinking ?
Yes, let's think about how people discover these versions files once we have released this.
-
[Bug Report] No warning for duplicate app password -
[Bug Report] No warning for duplicate app passwordWell, I should have tried it before replying. I can reproduce the problem
The problem is the dialog just stays open and does nothing. -
[Bug Report] No warning for duplicate app passwordThe text is just a label. It is not required to be unique. I guess once you detect it is conflicting, you have to rename the label to something else. Probably using creation date to differentiate.
-
Update on community packages@girish awesome, thank you so much.
Very smooth and integrated in UISo, making sure I understand it correctly, for a CustomApp, the packager really just needs to add
CloudronVersions.jsonto their repo (in addition to CloudronManifest.json, Dockerfile etc.) ? Neat !You said in a separate post you would defer the question of a catalogue of custom apps : is that still the thinking ?
TBH, with your neat approach, I am questioning whether a catalogue is needed. Every custom app (well, 99.999%) has a topic in the forum's AppWishlist category, and the packager can just post a message there with the repo details, including the relevant CloudronVersions.json file.
