Git push deployment method (+ Caprover)

Feature Request
#1

Similarly to FTP deployment, add an option “Git push” for deployment

Logic for Git push deployment:

  1. Once deployment is requested, create a new Git branch “wappler_deployment” (project must be using Git)
  2. Commit files to “wappler_deployment” (target specific files, such as db.json)
  3. Git push branch “wappler_deployment” to remote specified during target configuration
  4. Delete branch “wappler_deployment”

The same logic could be applied to Caprover. Instead of “git push”, it would be “caprover deploy”

Git push can be used for deployment with Dokku - a self-hosted Heroku alternative

Git or sftp?
Small helper script for Caprover users (Linux/MacOS/WSL)
Custom Deploy button
#2

General git deploy is definitely on our todo list! Just commit and push the master.

Already implemented for platforms like Heroku, need to make it more generic now.

Not sure what is exactly the advantage in your via an special wappler_deployment branch…

There are different git deploy strategies. Git flow seems useful.

But we tent more to go for the most simple master branch deploy.

1 Like
#3

I don’t want the credentials (e.g.: db.json) to be published to the master repository, where theoretically every developer working on the project could see it. By creating a wappler_deployment branch, such branch can be used for Git deployment only, so production credentials don’t end up in master

Until proper UI support for ENV variables is achieved, I believe creating this separate branch is the way to go

Edit: And I would .gitignore the folder of the “Git push” target (.wappler/targets/Git push), to prevent committing those to master branch as well

2 Likes
#4

How exactly would you like to see the ENV variables implemented on the UI? Per target? Maybe file another feature request with more in depth explanation.

Environment variables UI
#5

Disclaimer: I’m fairly new to Wappler so I might miss a point or two

I checked out Caprover for our current project and it doesn’t have an API so the only way to define ENV variables is either via Git or by defining them manually. Defining them manually is fairly easy and then using the values in Wappler dynamically {{$_ENV[‘whatever_env_value’]}} works well.

I decided to build a different stack though with Docker, Portainer, Swarmpit, Grafana, Prometheus, Traefik, Unsee, Drone CI, and GitHub, That works like a dream because it allows easy auto-scaling thanks to Traefik and Portainer`s API. Portainer has an endpoint for everything you can do with their UI and their community version is still open source. So they allow defining ENV values via API and that might be easier for Wappler to implement.

1 Like
#6