if the “adonis” preconfigured is suitable för Quasar?
I think you can make it work, it just adds some hooks that you can disable and replace with your own.
However, you should start with nodejs type and add your own hooks. I don’t know much about Quasar but I don’t see why it wouldn’t work. nodejs type uses pm2 start as well, you just have make sure of two things:
Add a new Build Hook and add what it takes to build app (like say npm run build --production
Make sure the entry point and the args are set correctly under webapp settings
Usually, when someone gets 502 it is because of the PORT address. Make sure that it is not hard coded to something like 3000. The port address is passed as an env variable so you can use something like process.env.PORT.
Check the logs of both the app as well as inspect the output of a deployment, you might get some hints on how it is not working.
Adonis has server.js as entry file in root and i saw Canary wanted index.js. I couldn’t find where to change this so i simply renamed server.js to index.js and now it works perfect.
This looks very promising. I will try to get Quasar to run now.
I’m glad you made it to work. Regarding Canary, it should be using the same entry point as that of the main application but you may have found a bug. We are already looking into it and will fix it right away. Thanks for your progress report and looking forward to more.
Only one issue to solve for me with Adonis and that is my uploaded files that lives in public/upload
Everytime i deploy i loose this folder since it isn’t part of git repo. I need to put this folder in root and somehow have an symbolic link added in current just like with .env file and make a hook to do this every deploy.
The quality of the product is of course important but the competent support is really important and so far this looks very promising.
I wonder what “Clean Old Deployments” does? How many old deployments is saved in the list?
I need to remove the shared folder in previous release otherwise my server will fill upp pretty quick.
AVAILABLE VARIABLES has releasePath and i guess this is the new path during deployment but it would be great to hav access to previousReleasePath so i can remove it.
I want the shared folder only in the latest release.
Clean deployments will remove older deployments. Cleavr keeps the last 5 successful deployments. If you need to free up space sooner, you could SSH into the server and remove the shared folders from the older releases.
The script in the custom deployment hook will link to the folder and doesn’t copy it, so that shouldn’t create a storage issue.
Not in the entry point on the webapp settings page. You can add in just dist/ssr/index.js for entry point. Release path is already part of the activation step which refers to the entry point you enter.
I tried out deploying a basic Quasar SSR project. I believe you mentioned this but I overlooked what you were saying about the build process. Since building outputs the web files in dist/ssr directory, you could then add a deployment hook just before activation that moves the contents of that folder to the root directory, {{ releasePath }}, and then simply add index.js as the entry point in settings (with no args).
However, since you brought this up, we’ve been wanting to simplify setting up nodejs apps and make it more scalable for different node frameworks. So, we have something really cool that we’re just about done testing that will make this all much more simpler.
This is so great, works like a charm. Sweet with more Node.js options but i don’t mind solving this with my new hook:
move build to root
mv {{ releasePath }}/dist/ssr/* {{ releasePath }}
Anyway, this was the last dealbraker for me. Just som more testing and then i will move away from Plesk and jump on the Cleavr train
Back int the PHP/Laravel days i used a service called Laravel Forge with similar no down time version deployment with rolback function. This works just like that and it’s super great.
With Plesk i have to manually do fetch from git, install npm uppdates, build new SSR and finally restart the Node process. If something goes wrong i have to revert changes in my codes, puch to git and do the whole process again. God this is more convenient and safe
Tanks again for excellent support, can’t wait for what the Cleavr future awaits.
We’ve released the updates to creating and deploying NodeJS app types.
For new sites, you now can now select between NodeJS SSR and NodeJS Static, add a build command, define an artifacts path, and deploy!
This makes it a bit easier for you as you won’t have to add the custom deployment hook to new Quasar web apps to move the build output artifacts into the root directory.
We were in the same boat, using GitLab because of the free team allotments; but we have since moved to GitHub.
For now, we have the integration with GitHub Actions for building and so users can further configure workflow for their needs. GitLab has their own version of Actions, but we haven’t looked at it yet and we’re unsure as to if or when we’ll tackle GitLab.
So now i have moved back to GitHub and it looks fine.
I notised that Hetzner offers servers in Finland and since i am in Sweden i chosed Hetzner.
I have done everything i did with DO (i think) but the Deployment gets error in first step Copying from Provider. I dont get any error log so i don’t know what is failing.
You don’t have to (we ourselves use Hetzner Servers). We got an alert about permission failure with a Hetzner Server. It could be your server. It could be that the APi key expired? If the copy project is failing then it could be that GitHub was down during deeployment? We will dig more into it and see what we find.
