how to automatically deploy to firebase on commit to main branch? - firebase

The Main part
I am trying to create a comfortable workflow for myself. I just want to know is there any way to automate deploys from GitHub Repo to Firebase hosting when I commit changes in the repo's main branch at my desktop and push origin to GitHub?
...possibly using "GitHub actions"...
Context and what I've tried
As on 15-Jan-2022 there are two ways I found of deploying website files to firebase hosting.
The de facto firebase cli way, where you use firebase deploy command to push files to firebase hosting.
The automated way using github actions, where the site is deployed automatically every time a pull request is created.
The first one is tedious, the second one is not my cup of cake. Especially because the workflow I want to setup is not too much git oriented, I don't use "pull requests" as far as I understand. I just commit changes directly in the main branch.
(That is so because, I am not a programmer, I just trying to create a blogging site using the Firebase hosting + GitHub repo)
I also referred https://medium.com/firebase-developers/the-comprehensive-guide-to-github-actions-and-firebase-hosting-818502d86c31

Use Deploy to live & preview channels via GitHub pull requests. It will work if you use pull requests to review changes or if you push commits directly to the primary branch.
I would recommend that you use pull requests though. It's a great flow to double check your changes and with the Firebase action it will deploy a temporary preview of the the changes so you can validate everything looks correct.

Related

Firebase RemoteConfig - different configs for different channels

Context:
I'm building a recipe website with Angular frontend and Node.js express backend.
I'm using Heroku for the backend and trying to use Firebase for the frontend. The backend is not ready for use, and is unstable. The frontend is almost ready for v1. For now, all I have is the ability to retrieve a list of recipes from the GET /api/recipes endpoint, and display them (and search through the loaded recipes). Eventually, I plan to add the ability to add/edit/delete/search through the recipes, as well as other endpoints. For now, it works equally well with a static .json file or a dynamic GET endpoint.
In the process of adding this to the backend, the backend will naturally go down and may become temporarily unusable at times, so I'm of course going to have two deployments of the API, and two deployments of the frontend. Prod and Dev, Live and Preview. This should be easy with Heroku, but Firebase is giving me some problems.
I want to have different configs for different deployments. A way for the front-end to ask Firebase "Where's the API I'm supposed to use". This shouldn't go in the repository, code once deploy many, yada: https://12factor.net/codebase . But I haven't figured out how to do this with Firebase.
Goal:
Firebase Remote Config should use a condition such as App Channel to send a different api_url parameter based on what channel the deployment is. This should not be stored in the repository. It should not give away the other deployments etc.
Whatever config I use should be build-once deploy-many. I do not wish to pass a config parameter such as configs:{"recipes.web.app":{apiUrl:"..."}, "recipes-preview-1239j20.web.app":{apiUrl:"..."}}. The frontend must not be aware of other deployments. It shouldn't even really have to be aware of where it's being hosted.
Current Progress:
I successfully deployed different versions to the live channel and the preview channel. I successfully made a RemoteConfig config using GUI (https://console.firebase.google.com/project/<project_name>/config). I did see how to add conditions. I successfully accessed RemoteConfig inside my custom service in Angular. I did find out that init.json on the preview and live channels are identical. I did successfully limit it to "If it's the recipe app", but it's useless because everything's the recipe app. There is a way to make multiple sites, but that's not really useful either, because I'd have to set up the entire app again.
I did not manage to figure out how to deploy remoteconfig.template.json from command line. I did not manage to figure out what conditions are useful. I did not manage to get the "Version" condition to be enabled in the condition selector. I did not manage to find any condition about "channels". I did not manage to find anything with "remote config" and "channels" even on the same page! I did not manage to find anything in firebase docs about "deployments".
Alternative and Unrelated Sidenote:
I'm extremely frustrated with Firebase, and if I can't figure this out, I'm going to abandon it in favor of a Heroku thing I just found. An "unsupported" buildpack for nginx (https://elements.heroku.com/buildpacks/heroku/heroku-buildpack-nginx). "Unsupported" as in it's unofficial. I'm familiar with nginx, and using that will make everything about this personal project (except the server location and build/deploy process) match up with what I'm doing at work. And also both halves of my personal project (static web and api) will be on the same host, which might make things nice.

How to deploy different versions of a web in different url path in Firebase Hosting?

I want to automatize the deployment of a web on Firebase hosting on each pull request in git hub with Firebase CLI. I want to deploy the version of the web of a pull request in a specific URL path.
For example, if the name of the branch of a PR is backend/100, I want to upload the web on https://<project-name>.web.app/backend/100. Then if I go to https://<project-name>.web.app/backend/100 I can see the version of the backend/100 branch, or If i go to https://<project-name>.web.app/backend/180 I can see the version of the backend/180 branch.
There is a way to achieve this?
Firebase supports multiple pages per project. But it will look like whatever-name-you-choose.web.app (not even necessarily the same project name), say project-name-branch-name.web.app.
In terms of doing routing, "backend/100", you'd have to develop a work-around..

How can I work on an existing Firebase (functions) project on a different machine?

I'm relatively new to Firebase and want to work on one Firebase Project from multiple Machines. When setting up a new Project locally via firebase CLI and attaching it to an existing Project in the cloud, there's a full project folder created in my local directory.
Is there any chance of sort of "downloading"/updating an existing project to a second machine?
The workaround I'd have chosen would be to manually copy the whole directory to the new environment and then login firebase.
But this would, given the fact of missing source control, bring the risk of overwriting changes made on machine 1 yesterday, when firebase deploy from machine 2 today, wouldn't it?
Sorry for maybe not expressing myself in a decent it-guy way, but I'm far from being a full-blooded programmer.
Thanks!
You have to manage your source code yourself, typically using a source control mechanism such as git or svn. Firebase does not provide a source control system for the code and configuration that you deploy to Cloud Functions.

Sync wordpress plugin updates to git repo

I have a wordpress site that I am finally getting into git. Previously I was editing changes locally and uploading via ftp. I want to come up with a strategy to be able to do the following:
Update my git repository with any changes made on the ftp server (plugin updates etc). That I will then sync that down into my local copy
Push locally tested changes into git and then deploy via ftp (I know how to do this part)
I don't know the best way to approach 1 and I'm very new to using git (usually use svn).
Thanks
Using a conventional development workflow on Wordpress is challenging.
Because WP puts too much in the database, including site config, it makes syncing changes from one environment to the other a real pain.
We have a number of WP installs (against my better judgement) and organise our workflow like this.
You might lighten this process if you're not part of a dev team and are going alone.
Local Dev
codebase changes only. Including shortcode development and templating. This lives under a GIT workflow (branches, tags, etc). Plugin/framework updates are installed here, and tested before adding to the gitball.
Beta Live
All content is built here, with any code based changes being requested as needed. Testing is carried out here, responsive, UAT etc.
Code changes are pushed up via deployment scripts which trigger either a GIT pull, or by syncing files via ssh:rsync. heres a good resource on how to use git hooks for this.
Live
For live deployment, we use a WP database migration plugin to get content across, and the git repository to push tagged releases up to the live server. We also use the sync tool to pull down up to date copies of the database to our local dev machines.
I'm sure there are lots of other opinions on what's best, and how to implement them.
My opinion
The fact is is that WP is a bad choice for websites that require a lot of under the hood attention. It was never designed for this, and consequently is a real pain to force into a proper development cycle. If I must use a CMS, I generally use Drupal for sites that need more functionality, its a steeper learning curve, but more than worth it.
You could follow a git flow pattern. This consist of three main branches:
master
release
develop
Preform all of your development in the develop branch which you would build and test locally. Then when you are ready to test on a server merge your changes into the release branch for testing. When everything checks out you can then merge into your master branch. From here you can either manually ftp the files from the master branch like you have been or set up a deployment hook to automate deployment to your server when changes are detected.
As your project grows you can implement a couple of other branches to further maintain your build. You can base a new branch feature off of develop when you need to add a new feature then merge it back into develop following the flow back up again. As well as a hotfix branch to take care of any bugs "on the fly" straight off the master branch.
Here is a good example of the git flow pattern:
[http://nvie.com/posts/a-successful-git-branching-model/][1]
This article goes into a lot more detail about the git flow pattern and is an awesome resource!
Be sure that whenever you start a new development phase you merge from master to develop so you know you are starting with the most recent version of your project.

How to delete site via CLI

Is there a way to delete an app via Firebase CLI?
Our CI creates a temporary Firebase app for a feature branch (based on the CI build number), and then runs tests on it. At the end it needs to delete the app. I'm not entirely sure how this is done. firebase disable:hosting just disables hosting and does not delete the app. This is similar to how we would have used Heroku review apps or Heroku forked apps. A similar CI workflow can also be achieved on Google App engine via versions.
Any pointers would be much appreciated.
The correct command is firebase hosting:disable, which make your site offline. You can not remove your project, instead you can overwrite it by creating a new one with firebase init.
More info here https://firebase.google.com/docs/cli/.
There is currently no public API to delete a Firebase backend.
The recommended practice is to use the same database for testing and (if needed) put each run in its own node under the root. So instead of creating/deleting a new database, you're just create/deleting a node in a single database.
Using the command firebase use <alias> --unaliasand then delete the project from the console https://console.firebase.google.com/
Check before the list of commands with the command -h

Resources