• Email subject:

[{{ priority }}-{{ state }}] {{#replace "/query.*minutes on/" annotations.title.[0]}}-{{else}}{{entitiesData.names}}{{/replace}}

• set -e, -u, -x, -o pipefail
• set -e
• set -x
• set -u
• set -o pipefail
• Setting IFS
• Original Reference

NOTE: When using Trivy, it will download a Vulnerability DB, Java Index DB, and Checks Bundle during every run. This quickly triggers rate-limiting errors. The script below will pre-cache the DB's every 24 hours, to ensure that excessive MegaLinter scans do not trigger rate-limiting.

#!/usr/bin/env bash

Pay attention to these importants facts regarding Sonar inclusions/exclusions:

• SonarQube, an opensource product, calculates coverage using percentage of lines-of-code (LOC) covered by tests.
• SonarCloud calculates cost based on lines-of-code (LOC). This only applies to private repositories.
• Adjust relative paths in sonar.sources and sonar.exclusions config properties to match your requirements.
• Only scan the files you've written. DO NOT scan external libraries.
• If you must scan large amounts of code, use an ephemeral SonarQube instance to reduce cost.

TLDR: lscolors generator tool: [http://geoff.greer.fm/lscolors/]

The value of this variable describes what color to use for which attribute when colors are enabled with CLICOLOR. This string is a concatenation of pairs of the format fb, where f is the foreground color and b is the background color.

The color designators are as follows:

This approach uses the Upstream Sync GitHub Action to keep a remote/origin in sync with the remote/upstream repo.

1. Create and navgiate to, directory for repo: mkdir <repo_name> && cd <repo_name>
2. Initiate a new git repo: git init
3. Add upstream remote config: git remote add --tags -t upstream git@github.com:/.git

--- Server-side

• Build AMIs

If you want to run your apps directly on EC2 Instances, you should package them as Amazon Machine Images (AMIs) using a tool such as Packer. Although we recommend Docker for all stateless apps (see below), we recommend directly using AMIs and EC2 Instances for all stateful apps, such as any data store (MySQL, MongoDB, Kafka), and app that writes to its local disk (e.g., WordPress, Jenkins).

• Deploy AMIs using Auto Scaling Groups

The best way to deploy an AMI is typically to run it as an Auto Scaling Group. This will allow you to spin up multiple EC2 Instances that run your AMI, scale the number of Instances up and down in response to load, and automatically replace failed Instances.

• Build Docker images >> If want to run your apps as containers, you should package your apps as [Docker](http://d

I hereby claim:

• I am seantrane on github.
• I am seantrane (https://keybase.io/seantrane) on keybase.
• I have a public key ASBzyNMCrHYsez6rHgpQB1cJ89pgoMQatRJzoqZHqUFx3go

To claim this, I am signing this object: