Skip to content

Latest commit

 

History

History
103 lines (75 loc) · 5.76 KB

README.md

File metadata and controls

103 lines (75 loc) · 5.76 KB

Github Actions <> Zeit integrations

Automated actions configured through GitHub Actions

This documentation explains how our GitHub actions integrate themselves with the Zeit platform

Getting started

Introducing GitHub Actions

Stuff to read if you're not familiar with GitHub Actions

Official documentation

Most useful documentation links:

Requirements

List of necessary requirements for the Github Actions <> Zeit to work properly.

Required GitHub secrets:

Those secrets must be added on Github settings page, such as https://github.com/UnlyEd/next-right-now/settings/secrets

Overview

Stages

We use two different stages. Each stage is meant to use a different configuration.

staging (see deploy-zeit-staging): Every pushed commit, (except those made on master) automatically starts a new Zeit deployment, using the related staging configuration file. You can choose which client you deploy by changing the symbolic link now.json file.

production (see deploy-zeit-production): Commits pushed to the master branch will automatically deploy the now-production.json configuration.

N.B: Those events are triggered by pushed commit, but also merged branches.

GitHub Actions Jobs workflow

The same workflow is used for both stages. The main difference is the trigger.

A production deployment is triggered by any change in the master branch, while a staging deployment is triggered by any change that is not on the master branch.

Jobs workflow:

  • Installing Node.js and npm dependencies, by specifying Node version
  • Deploy code:
    • We checkout to the last branch commit, documentation here
  • Run 2e2 tests:
    • We need to checkout again (because the code is not persistent)
    • We ask to Zeit api for the last deployment data, retrieve the url and then set it as environment variable as ZEIT_DEPLOYMENT_URL (to be able to use it afterwards)
    • We use default action provided by cypress (documentation here):
      • wait-on: Allows us to wait before starting tests. It ping the endpoint until it's up, with a timeout of 60 seconds per default.
      • config-file: We need to specify a config file because cypress is looking for cypress.json in the main folder. The config file itself doesn't matter because we will override most settings anyway. We just need projectId to run the tests.
      • config: Overrides some default config, like the baseUrl in particular (we use the ZEIT_DEPLOYMENT_URL instead)
    • We upload artifacts on tests failure, more documentation here

Dependencies

Actions

Complex commands