chore(ci): use single branch pattern for deployments (#3568)

* chore(ci): remove dependency on master

* chore(ci): introduce approval step

* chore(ci): remove branch filter

* docs: remove mention of production branches

* chore(ci): remove defunct code paths
This commit is contained in:
Luke Watts
2024-05-21 23:35:53 +02:00
committed by GitHub
parent 3f288b2d43
commit 8f7fc6830a
8 changed files with 21 additions and 90 deletions

View File

@@ -77,12 +77,7 @@ aliases:
ls -a ~/project
du -a /home | sort -n -r | head -n 500
- &filter_only_production
filters:
branches:
only:
- production
- &filter_only_master
- &filter_only_default_branch
filters:
branches:
only:
@@ -388,25 +383,13 @@ workflows:
jobs:
- spellcheck:
name: Check documentation spelling
filters:
branches:
ignore:
- production
- lint-commits:
name: Lint commits
filters:
branches:
ignore:
- production
- lint:
name: Lint code
requires:
- 'Check documentation spelling'
- 'Lint commits'
filters:
branches:
ignore:
- production
#---------------------- Test ----------------------
# Note - when calling test we also let the test script handle building as it injects random variables for seeding the DB
- build:
@@ -418,51 +401,27 @@ workflows:
name: 'Unit tests'
requires:
- 'Lint code'
filters:
branches:
ignore:
- production
- test_circular_dependency:
name: 'Circular dependency test'
requires:
- 'Lint code'
filters:
branches:
ignore:
- production
- storybook:
name: Build Storybook
requires:
- 'Lint code'
filters:
branches:
ignore:
- production
- test_security_rules:
name: Test Security Rules
requires:
- 'Lint code'
filters:
branches:
ignore:
- production
- test_functions:
name: 'Cloud Function tests'
requires:
- 'Lint code'
context: build-context
filters:
branches:
ignore:
- production
- test_functions_upload_coverage:
name: 'Upload Cloud Function coverage'
requires:
- 'Cloud Function tests'
filters:
branches:
ignore:
- production
- test_e2e:
name: e2e-<< matrix.CI_BROWSER >>-<< matrix.CI_NODE >>
requires:
@@ -478,16 +437,12 @@ workflows:
parameters:
CI_NODE: [1, 2, 3, 4]
CI_BROWSER: ['chrome']
filters:
branches:
ignore:
- production
#---------------------- Development Instances Build and Deploy ----------------------
- deploy:
name: 'Deploy: dev.onearmy.world'
requires:
- test_e2e
<<: *filter_only_master
<<: *filter_only_default_branch
DEPLOY_ALIAS: 'default'
context:
- circle-ci-patreon-context
@@ -496,7 +451,7 @@ workflows:
name: 'Deploy: dev.community.projectkamp.com'
requires:
- test_e2e
<<: *filter_only_master
<<: *filter_only_default_branch
DEPLOY_ALIAS: project-kamp-development
context:
- circle-ci-patreon-context
@@ -505,28 +460,34 @@ workflows:
name: 'Deploy: dev.community.fixing.fashion'
requires:
- test_e2e
<<: *filter_only_master
<<: *filter_only_default_branch
DEPLOY_ALIAS: fixing-fashion-dev
context:
- circle-ci-patreon-context
- fixing-fashion-dev
- approve:
type: approval
name: 'Approve Production deployment'
requires:
- 'Deploy: dev.onearmy.world'
- 'Deploy: dev.community.fixing.fashion'
- 'Deploy: dev.community.projectkamp.com'
#---------------------- Development Instances Build and Deploy ----------------------
- release:
name: Release new version to GitHub
<<: *filter_only_production
context:
- release-context
requires:
- "Approve Production deployment"
- build:
name: Build Production Release
context: build-context
requires:
- 'Release new version to GitHub'
<<: *filter_only_production
- deploy:
name: 'Deploy: community.fixing.fashion'
requires:
- 'Build Production Release'
<<: *filter_only_production
DEPLOY_ALIAS: fixing-fashion-prod
context:
- circle-ci-patreon-context
@@ -535,7 +496,6 @@ workflows:
name: 'Deploy: community.preciousplastic.com'
requires:
- 'Build Production Release'
<<: *filter_only_production
DEPLOY_ALIAS: 'production'
context:
- circle-ci-patreon-context
@@ -544,7 +504,6 @@ workflows:
name: 'Deploy: community.projectkamp.com'
requires:
- 'Build Production Release'
<<: *filter_only_production
DEPLOY_ALIAS: project-kamp-production
context:
- circle-ci-patreon-context

View File

@@ -13,7 +13,7 @@ name: "CodeQL"
on:
push:
branches: [ master, netlify-preview, production ]
branches: [ master, netlify-preview ]
pull_request:
# The branches below must be a subset of the branches above
branches: [ master ]

View File

@@ -1,27 +0,0 @@
name: Create Release PR to production branch
on:
# Triggers the workflow on push or pull request events but only for the `master` branch
push:
branches:
- master
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "deploy"
deploy:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
- name: pull-request
uses: repo-sync/pull-request@v2
with:
destination_branch: "production"
github_token: ${{ secrets.GITHUB_TOKEN }}
pr_title: ":robot: Release PR"
pr_label: "🦾 Automation"

View File

@@ -1,5 +1,5 @@
{
"branches": ["production"],
"branches": ["master"],
"ci": false,
"plugins": [
[

View File

@@ -80,14 +80,14 @@ We have a small bounty system as a way of saying thanks to developers for contri
## 🌳 &nbsp; Branch Structure
We have two main branches linked to production and development sites, you should always start with the `master` branch as this contains the most up-to-date code, and will be where pull requests are added for review. The `production` branch contains the live production site, PRs are automatically raised that will merge changes in from `master`. Maintainers are responsible for merging these PRs.
We have a single main branch which is linked to production and development sites, you should always start with the `master` branch as this contains the most up-to-date code, and will be where pull requests are added for review. Once a branch is merged into `master` it will be deployed to the development environment. The maintainers will then approve for deployment to the production environment.
We use additional branches to define a specific feature or issue group being worked on. An example might be work on the home page, which would be done in the `19-home-page` branch (where 19 refers to the issue number describing what needs to be done). These branches are ephemeral, and will be removed after merging into `master`, followed by closing the issue. Generally it is expected that only 1 developer will be working on a given branch, and it is that developer's responsibility to create the branch, manage the pull request, reviews and ask for additional support when needed.
## 🚀 &nbsp; Deployment(s)
The `master` branch is our current development leading branch, and will auto-deploy to the
development environment. The `production` branch deploys to the production environment.
development environment, after a manual approval step this branch will be deployed to our production environments.
| | Development | Production |
| ---------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------- |

View File

@@ -27,7 +27,7 @@ Future
## How to build and deploy
The functions are integrated into the ci pipeline for master and production branches.
The functions are integrated into the ci pipeline for the default branch.
Simply make a PR and once approved the function will be deployed
## Testing locally

View File

@@ -46,9 +46,8 @@ The steps are as follows:
- The PR is merged into the `master` branch.
- `master` branch triggers an automated build and deployment to development environments.
- A Release PR is automatically raised to merge `master` into the `production` branch.
- Manual approval is required by a maintainer, then merge Release PR into `production`.
- After merge, an automated build, versioning, and deployment to production sites.
- Manual approval is required by a maintainer in CircleCI
- After approval, an automated build, versioning, and deployment to production sites.
# Rewards:

View File

@@ -32,7 +32,7 @@ Troubleshooting:
## Community Platform Maintainers
We deploy to our instances directly from the `master` and `production` branches of the git repository.
We deploy to our instances directly from the default branch of the git repository.
You will need to set up a CircleCI context for each target environment. This context should contain the following variables: