Cloudron Forum

girish

@timconsidine said:

cli revoke only revokes the last entry, user might want to revoke previous ones

Good catch, added this now. cloudron versions update already had --version.

docs for CLI should explain more about 'cloudron build' and 'cloudron build build'

For the tutorial, we switched to using source builds as the default approach. The next "advanced" step is to build using a local or remote builder. https://docs.cloudron.io/packaging/tutorial#alternative-build-methods explains cloudron build and automatic tags.

TBH, most people don't read docs despite all this The longer the tutorial, the even lesser it will be read.

murgero

@timconsidine I just have a quickie script:

docker build -t tag . --no-cache
cloudron install --image=tag

timconsidine

@murgero I'm with you

The bash build script I am building uses a parameter :
echo " -p 0 = install only, 1 = publish (revoke/add/push)"

If command has -p 0, it does cloudron install --image ....

If command has -p 1, it does cloudron versions add etc.

Not sure how it will work in practice, needs some real-world usage.

murgero

Yeah the build process I have I actually avoid using cloudronversion for testing the install until I see it work with cloudron install --image first. I dont mind it taking time but its a janky build process. CI/CD goes a long way but I can't be bothered atm lol

timconsidine

Trying to smooth my workflow for CommunityApps (w/o mentioning Safari ) ...

given that CloudronVersions.json is, well, a JSON file, presumably we can edit it if needed, then give access (git repo, static site) ? 2 scenarios I've met are :
- (a) cli revoke only revokes the last entry, user might want to revoke previous ones (parameter to specify which to revoke would be nice),
- (b) docker image location might be wrong ... or moved ... and don't want to repeat build workflow

publishing docs should make explicit a clear expected workflow (dangerous assumption that I have this correct), maybe with a pic for fast absorption w/o reading
- do your dev
- update CloudronManifest.json & CHANGELOG
- do your build / push
- run cloudron versions add
- commit/post CloudronVersions.json
- test / loop

docs for CLI should explain more about 'cloudron build' and 'cloudron build build' (repeat words does my head in BTW, please don't )
docs should make clear that 'cloudron build' will auto assign a tag if not provided ?

CHANGELOG is great discipline ... but I am not disciplined :
- presumably we can mock it out ("frig it" in AngloSaxon) to make 'cloudron versions add' work, ...
- or better question, can we automate it (use a publish script to bump version in CloudronManifest.json, maybe with user input, replicate in CHANGELOG, do cloudron build, run cloudron versions add, commit to git, push CloudronVersions.json to static location), ...
- or EVEN BETTER question, how do you as pro devs handle this ? I'm guessing not manually.

can we please have some short options for things like :
- '--build-arg <namevalue>' [maybe '-a' or '-arg' or '-ba']
- '--repository' [maybe '-r' or '-repo'].
- Even '-nc' for no cache and '-np' for no push (others are ok).

Although I guess they are probably in a script so maybe it does not matter.

girish

Fixed. Thanks for reporting.

girish

@pdrupp great guess. You are exactly right, it's cycling through all the users and printing the message for the users it did not match. We will fix it.

girish

@umnz @lars.emil Can you please try the latest package 4.13.0? @james helped me test and it should work now.

girish

@umnz https://git.cloudron.io/packages/n8n-app/-/merge_requests/158

girish

@umnz I found the problem. The location of musl is different in alpine and ubuntu. Making a new package.

Our tests are not comprehensive enough to detect workflow errors. They only test if n8n comes up and one can login etc. Have to improve this.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

AppDev

Posts

Member List