fortrabbit already has Git and even Composer build in without the need of any extra service. But fortrabbit currently does not offer a Node.js runtime during deployment, so common build tasks (Webpack) can not run here. So, one good use case to implement GitHub Actions is to automatically build static assets, like and JS, CSS. Or you can test and do other advanced stuff before deploying to fortrabbit.
You will need to generate an SSH key to allow GitHub to access your fortrabbit App. Start in the Terminal of your local computer (not the fortrabbit App):
- Create a key pair:
$ ssh-keygen -t rsa -b 4096 -m pem -f /tmp/key-github. This will generate two files:
/tmp/key-github. The first one is the public key, the second one is the private one.
- With the fortrabbit Dashboard, go to your App and add an App-only SSH key. Paste the content of the public key. This will allow anyone or any app having the corresponding private key to access this app.
- On your GitHub repository, go to the Settings, and then go to Secrets. There, add a new secret, call it
SSH_PRIVATE_KEY(if you want to follow our example, but you can obviously call it as you want), and paste the content of the private key.
- Now you don't need the keys in your local
/tmpfolder anymore and you're all set up.
We will show two ways to integrate GitHub actions, both can have the same result, but the approach is different:
1. Git transport layer method
Available for Universal and Professional Apps.
Here, you commit all files, including the uglified JS, inside the CI's temporary Git repository, then force push to deploy. You can use this example workflow YAML as a starting point:
As you may have noticed, we don't install PHP dependencies here, because when a Git deployment happens with fortrabbit, a Composer install is automatically triggered.
2. rsync transport layer method
Only available for Universal Apps.
Here we will use
rsync to deploy to fortrabbit at the end. Instead of dealing with a temporary git repository in the CI that you alter, you can directly send all the files through rsync.
A Composer install in GitHub's CI is triggered. Since the fortrabbit Git repo stays untouched, hence no Composer process will be launched on the deploy service. Everything will be transferred to fortrabbit already packed.
Please let us know what you think! We are actively considering different implementation ideas.
What would you prefer: Having Node.js directly integrated with our service without the need to use an external service for this, or better integration with GitHub (and/or maybe BitBucket and others)? What do you think about the two approaches outlined above? Do you fully understand the differences? What would be your setup? Maybe, what's your use case?
Thanks to our smart clients
We have mentioned this many times before, but we really do enjoy having such smart clients, constantly requesting features and producing edge cases. It helps to shape and build our services. This blog post and the actual prototype was heavily inspired by diesdas.digital!