Hi, we have been building an open source application for animal shelters https://app.petbook.lt/ for the past year and we have found great value in GitHub Actions. The application has separate Back-end and Front-end repos and they both utilise GitHub Actions notably. The application had been started as part of KAYAK WeCanCode Academy https://www.wecancode.lt/ event in Kaunas to teach the local community in Lithuania to code and at the same time create software for the common good.
This software for animal shelters is meant to help document homeless and already in-shelter animals as well as to ease the adoption of these animals.
Lately both repositories have been losing traction (since summer) resulting in only very few developers that also barely find time to build this great software. However, I hope that winning a prize in this event will bring back the enthusiasm to continue building it!
My Workflow
When we started this work, we thought we would have it built long ago. Like with all software estimation, right? However, this open source application still needs some work to reach the minimum viable product (MVP) stage and I will guide it until it actually reaches the MVP and then we can hand it out to shelters to be tested and gather the feedback.
When we started these repositories, I had had never used GitHub Actions and even now they seem to be shockingly useful.
Both Back-end and Front-end repos use GitHub Actions to test and to deploy the code.
I mostly worked on the Back-end repo, thus I will mostly share my excitement in Back-end repo using GitHub Actions.
Unabashed, I am proud of our decision to always nuke and redeploy the database on deployment to simplify the database changes. This allows us to have the same structure database across local, dev, prod environments as well as "local" database within GitHub Actions. Only the entries can differ, the database description language (DDL) stays the same and it is all described in 1 SQL file https://github.com/pets-oss/pets-back/blob/main/database/1-schema.sql.
I must mention that we chose to always redeploy the database to ease the development and have all DDL in one file without any migration amendments but this is definitely not safe for a working application! We are using this path only until we reach the MVP. Later on, we would not like to redeploy the database and lose all the production entries that users have already entered!
To this I would like to add that I am also extremely proud of our approach to Dockerize this Back-end application together with a PostgreSQL database. This allows us to spin up the very same code application with a "local" database within GitHub Actions. It makes sure our tests run on the newest and robust code and database changes when making a pull request. To sum up, it ensures the very same database and code across all environments - local, dev, prod and even a "local" one in GitHub Actions Docker containers!
I am very fond of the GitHub Actions that allow to spin up Docker containers together with a database.
It is also tremendous to see the caching of libraries inside GitHub Actions.
Furthermore, both repos use Github Actions to deploy and to test the code. Back-end repo deploys to Heroku while Front-end repo deploys to GitHub Pages.
Install npm libraries with npm install command (if not installed previously).
Copy and rename database.env.sample to database.env. POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB can be adjusted to your liking, but the default configuration will work as well.
Copy and rename common.env.sample to common.envCreate a cloudinary account and replace the CLOUDINARY_URL variable
or
Set CLOUDINARY_DISABLED=true
name:'integrate'on:pull_requestjobs:test_pull_request:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v2-run:|yarn --no-progress --non-interactive-run:|yarn run lint-run:|yarn run test-run:|yarn run build
Before starting the setup choose what actions you will do with the code changes. If you will keep it as a local copy - make a repository clone. If you will contribute to the project - make a repository fork and read the Contribution guideline.
The project codebase is optimized for using Visual Studio Code which can be downloaded and used with the most of popular OS. Install Prettier and ESLint extensions as these are mandatory for project codebase consistency.
Get your local copy of the repository by cloning or forking.
If not yet installed, get Node JS (> 10v) and npm. Run node -v in your terminal to check the actual Node version. If you need to be able using various Node versions for your projects, consider installing and using Node version manager…