All Projects → PixelogicDev → gruveebackend

PixelogicDev / gruveebackend

Licence: MIT license
This is the Backend work for Gruvee

Programming Languages

go
31211 projects - #10 most used programming language
shell
77523 projects

Grüvee-Backend

Let's get Grüvee with a new social, collaborative playlist for iPhone and Android

Discord members online GitHub issues PRs welcome!

Getting Started · Running Grüvee Backend Locally · How to Contribute · FAQ · Current Contributors . Deployment Status

Grüvee is an open source social, collaborative playlist made by the PixelogicDev Twitch Community. This project was entirely made live, on Twitch while receiving help from chat and contributing to Pull Requests here!

This is currently the Backend portion of the platform. We are currently building a Mobile client that can be found here!

If you are interested in becoming a member of the team check out the PixelogicDev Twitch, the PixelogicDev Discord and contribute to this awesome project!

All Contributors


Getting Started

Tech Stack

Stack Tech
IDE Visual Studio Code You can use your preferred IDE but this is the one we like 🙃
Backend Firebase (Repo) Serverless Functions in Firebase using GoLang
Frontend React Native 0.60 Utilizing Javascript to develop this cross platform mobile app

ALL of these sections are open for contributions and are highly encouraged!

Running Grüvee Backend Locally

Golang Setup

We found this guide pretty helpful in understanding the Golang file structure and how it should be setup. We have tweaked this file structure to fit our Firebase Function setup.

  1. Make sure to install Golang we are using v1.13
  2. Find your GOPATH. ALWAYS located in this path ($HOME/go) unless put otherwise
    1. Example GOPATH: Users/YourComputerName/go
    2. Example GOPATH/BIN:Users/YourComputerName/go/bin
  3. Add GOPATH env variable
export GOPATH="$HOME/go"
export GOBIN="$HOME/go/bin"
export PATH=$PATH:$GOBIN:$GOPATH

Golang and VSCode Extensions

We have found some awesome workflows and tools to get us up and running with Golang. This repo includes a .vscode/settings.json & .vscode/extensions.json which will allow you to automatically download the recommended extensions and keeps your repo styling in sync with all the contributors. If you find more extensions please join the PixelogicDev Discord and share with us so we can add it to the project!

Grüvee Backend File Path

Make sure gruveebackend is in your GOPATH (This helps a lot. We promise.)

  1. Clone repo from Github
  2. Open up GOPATH/src/github.com/
  3. Create folder called pixelogicdev
  4. cd pixelogicdev and move/clone gruveebackend into this folder

Running Functions Locally

When you want to run all the functions locally, all you need to do is run scripts/gorun.sh. This will work out of the box on any macOS/Linux/Ubuntu system. If you are running on Windows 10 you will need to follow a guide like this to get the bash system running on your machine.

This script does the following:

  • Adds all the replace lines in all the go mod files
  • Builds and runs the main.go file in the root

Auto Tagging and Deploy with Github Actions

GitHub Actions is used for tagging functions when updated and pushing them to gcp. This is an automated process which has the following requirements:

  • Any change made in a function's folder structure (e.g. /cmd/appleauth/**) must be accompanied with a new version (maintained in .version file).
    • If a change is made to a function and the same tag is used again, the deploy will fail!
  • All code destined for master should/must go through a pull request (pr). No pushes should go directly to master, let's keep good habits!
  • GitHub Actions yaml files are kept at .github/workflows/
  • There is one Actions yaml file per function per trigger. This allows multiple functions to be updated in a push and each will be tagged and deployed as needed.
    • There is currently only a 'push to master' trigger file. Other useful triggers are on PR, which can run linting, tests, and even pushed to staging, vetting the code being staged for production deployment.
  • The tag written is taken from the first line of the .version file (e.g. - v1.0.0-beta.3: Tweaking...). The function used splits on the colon, uses the first half grabbing everything from the v forward.

Basic Workflow

There is a separate Actions trigger file for each function. The Action will trigger whenever there is a change in the functions directory (e.g. cmd/tokengen/*). The following occurs:

  1. The code is checked out
  2. The version is extracted from the first line of the .version file
  3. A tag is written to the merge's SHA using the version extracted from the file
  4. The config.yml file is written to disk
  5. gcloud action is loaded
  6. The deploy is run using the .deployment file from the function's directory.

Required Secrets

The Actions configuration requires four secrets to be configured in GitHub repo:

  • PROD_CONFIG_YAML -- The configuration file used by GCP for the function's variables
  • PROD_CONFIG_YAML_64 -- A base64 encoded version of PROD_CONFIG_YAML
  • PROD_GCLOUD_AUTH -- GCP service account which can deploy to the GCP project's function. JSON format with no carriage returns or line feeds
  • PROD_GCP_PROJECT_ID -- The GCP project id being deployed to

You may be wondering why there are both the yaml config file and the yaml config file base64 encoded. The base64 version is used to write the file used by the deploy process. The regular yaml version is used to redact all the values from the log. It's a work-around to ensure values aren't leaked in the logs. IT IS VERY IMPORTANT TO UPDATE BOTH OF THESE FILES WHENEVER THERE IS A CONFIGURATION CHANGE!

Setting up a new function for tagging and deploy on push to master

Each function has it's own GitHub Actions file under .github/workflows. At the time of writing all of these files are triggered on push master. The steps for creating a file for a function is very straight forward. There are only three lines to update (1, 8, 17).

  1. Copy template_pushMaster.yml file from the workflows template directory, .github/workflow_templates/, into the workflows directory, .github/workflows.
  2. Rename the file copied with the function's name. E.g. function tokengen would be renamed: tokengen_pushMaster.yml
  3. There are three lines to update in the file with the function's name: 1, 8, & 17
    • line 1: Replace [function name] with the function's name (e.g. tokengen)
    • line 8: Replace [function name] with the function's name (e.g. tokengen)
    • line 17: Replace [function name] with the function's name (e.g. tokengen)
  4. That is all, GitHub Actions is now configured for the function. (after the files are pushed to master that is 😃)
  5. Add a new badge to the Deployment Status page. You can get the badge from the Actions page or create from one of the existing ones by changing the function's name in the label and url.

Deployment Status

See Deployment Status Page to see the GitHub Actions deployment status of all the functions.

FAQ

To understand how certain aspects of this project work please see the FAQ Documentation!

🤘 Contributing Changes

See CONTRIBUTING.md

Contributors

Thanks goes to these wonderful people (emoji key):


Alec Dilanchian

💻 🚧 📖

Edgar Burtnieks

💻

Isabella Brookes

📖 🚧

Levi Harrison

💻

Brett Slaski

💻 📖

Dan

📖

This project follows the all-contributors specification. Contributions of any kind welcome!

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].