formidablelabs / badges Goto Github PK

I imagine plain ol' badges is already taken!

Here's an idea -- when creating a new PR deployment comment, delete the old ones so latest one remains the only one.

All the little-loader ones and others are not "unknown" status builds.

We have text logs which are not machine parseable / easily analyzable.

Task:

• Switch everything over to JSON
• Consider using a real logger like bunyan
• Review what data we are logging for additional tickets.

It's about time and we have some security warnings.

• deploy to production by tagging the branch
• merge after verification (github flow)

Refactor the GitHub Actions so that the ci/cd.js files can be deleted

Will need a new logs bucket.

Remove the CodeBuild jobs that were being used previously prior to the move to GitHub Actions. This is still being referenced in pull requests

Reproduction

$ yarn start:dev
$ open http://127.0.0.1:3000/sauce/Havunen?labels=none

• Expected: Get a badge or an error stack trace.
• Actual: Page hangs.

Work

Already begun in branch-of-branch: chore/docs-updates...bug/async-errors

We have lots of left over resources like:

• s3:tf-badges-nonprod-pr25-remote-state
• lambda:sls-badges-nonprod-pr36-app

We should:

• Scour and identify everything that's lingering around
• Identify why those resources aren't getting cleaned up
• Create a tool / document how to manually clean up easily.
• Fix / automate cleaning going forward.

Convert the CI tooling to Github Actions instead of Codebuild

The "badges" project will be archived and all runtime assets will be sunset. Based on our availability and traffic, the site receives very minimal usage and we expect little impact,

• stretch goal: per-PR environments

• Redirect to https://formidable.com/open-source/badges

Already set up in comments of DEVELOPMENT.md for work.

Options (not mutually exclusive):

• Document and use AWS-stored secrets
• Have localdev overrides for easier use
• Have localdev disables or what not.
• ???

The example link that we post during deployment: travis/infernojs/inferno/sauce/Havunen?name=InfernoJS is currently showing as browsers unknown. It seems that there may be an application issue with consuming Sauce

Issue

When building #39 two commits were pushed together than the CodeBuild pipeline for the second failed with:

[terragrunt] 2019/12/06 19:48:51 Running command: terraform apply -auto-approve 
 
Error: Error locking state: Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed 
    status code: 400, request id: RDALDDI7D8L8GP6N1O223N5I9BVV4KQNSO5AEMVJF66Q9ASUAAJG 
Lock Info: 
  ID:        749c2850-b113-76b5-3920-3753bf120ed1 
  Path:      tf-badges-nonprod-pr39cd-remote-state/terraform-cd.tfstate 
  Operation: OperationTypeApply 
  Who:       root@7c6a0ebec808 
  Version:   0.12.10 
  Created:   2019-12-06 19:48:49.086482789 +0000 UTC 
  Info:       
 
 
Terraform acquires a state lock to protect the state from being written 
by multiple users at the same time. Please resolve the issue above and try 
again. For most commands, you can disable locking with the "-lock=false" 
flag, but this is not recommended. 

presumably because the previous build hadn't finished.

Task

• Review and research approaches to mitigate this (delay and backoff for state lock or something in TF / terragrunt, ... ?)
• Implement and test fix with multiple near-in-time commits.

Tested multiple projects with Travis Sauce integration and none return badges!

Not for MVP, will require the in-progress terraform-provider-fastlyextra custom provider.

Although we use protected branches to prevent merges to master, we could have 2+ successive promotions of different PRs to production before merging the PRs and causing the CI protections to kick in.

• for MVP: use a global access token instead of a service-limited one (see #7)

• source env config (region, tier, stage, service name) from custom-environment-variables.js

Currently we rely on an actively running cloud infrastructure to get secrets.

• Create a localdev alternative, maybe with environment variables.
• Optional: consider disabling AWS cloud secrets usage.

• server should run on vanilla Node LTS
• remove all babel dependencies

Like https://github.com/FormidableLabs/aws-lambda-serverless-reference/blob/master/LEARNING.md appropriate to this more advanced project.

Removed the legacy CodePipeline that was used previously with CodeBuild. Was in place to allow for manual approvals and to run CodeBuild. This is now being done through GitHub Actions on pushes to master

I think we could do a lot better than badge-matrix-next 😉

I have deployed in docker and work fine but badges don't display when are embedded, but do when directly visited

Audit:

• All unused code.
• All unused dependencies.

and remove.

Including:

• All TF resources
• The state bucket / DDB locks for TF.

For reference see how we nuke versioned buckets in the reference app: https://github.com/FormidableLabs/aws-lambda-serverless-reference/blob/master/package.json#L35-L38

• use regional endpoint to avoid double CDN (we want Fastly instead of CloudFront)
• use custom domain to have a stable hostname to point to in Fastly

Can be either based on README markdown or a bespoke one, but we should have a very nice landing page for https://badges.formidable.com instead of the current redirect to this repository.

/cc @formidableamy

• Go through a full new environment.
• Enhance all the docs with everything that this entails.
• Tear it all down.

• Headings for DEVELOPMENT vs PRODUCTION
• Same as the PR comment does for staging build.

Right now it's just silent.

• IAM module updates manually, allows Serverless and Terraform "app" module to run in CI
• App module runs in CI, will provide support resources for Serverless (e.g. Fastly)

Add Formidable (C) underneath Brian Beck one (and preserve Brian's line).

We have a personal auth token for badges-ci that expired 11/15/2021. We probably have to create a new one and add it somewhere 😉