quick setup and usage guide for SSH access over SSM to private AWS EC2 instances
- python3
- awscli
- session-manager-plugin
git clone https://github.com/elpy1/ssm-tool.git
import fs from 'fs'; | |
import { parseSyml } from '@yarnpkg/parsers'; | |
import path from 'path'; | |
let file = fs.readFileSync('yarn.lock', 'utf8'); | |
let json = parseSyml(file); | |
// function make map with all packages and their versions. |
/** | |
* Primitive load-balancer to split Cypress specs across multiple runners. This script assumes that | |
* all your specs are in the folder '<project root>/cypress/integration'. It uses the number of | |
* tests per spec file as sole criteria to split specs between runners. | |
* | |
* This script accepts two arguments: the total number of runners and the index (starting from 0) of | |
* the current runner. Example: | |
* $ node cypress-partial.js 5 2 | |
* This command asks for specs to give to the third runner of five runners. | |
* The output of the script is a coma-separated list of specs that can be given to Cypress. Example: |
// @ts-check | |
"use strict" | |
/** | |
* Set up datadog tracing. This should be called first, so Datadog can hook | |
* all the other dependencies like `http`. | |
*/ | |
function setUpDatadogTracing() { | |
const { tracer: Tracer } = require('dd-trace') | |
const tracer = Tracer.init({ |
# Author: Daniel Brandenburg | |
# | |
# This program is free software: you can redistribute it and/or modify | |
# it under the terms of the GNU General Public License as published by | |
# the Free Software Foundation, either version 3 of the License, or | |
# (at your option) any later version. | |
# | |
# This program is distributed in the hope that it will be useful, | |
# but WITHOUT ANY WARRANTY; without even the implied warranty of | |
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
import React from 'react'; | |
import merge from 'lodash.merge'; | |
import { RedocStandalone } from 'redoc'; | |
import useThemeContext from '@theme/hooks/useThemeContext'; | |
import './styles.css'; | |
/** | |
* NOTE: Colors taken from `node_modules/infima/styles/common/dark-mode.css` | |
* and related files | |
*/ |
quick setup and usage guide for SSH access over SSM to private AWS EC2 instances
git clone https://github.com/elpy1/ssm-tool.git
#!/bin/sh | |
# Based on BMitch's answer from: | |
# https://stackoverflow.com/questions/38946683/how-to-test-dockerignore-file | |
# Note: will create and delete temporary file "Dockerfile.build-context" | |
# 1. Copy to project folder where image is being built | |
# 2. Run script | |
# 3. You should see list of files in build context |
#!/bin/bash | |
# | |
# Function that parses semantic versioning striings of | |
# the form: | |
# MAJOR.MINOR.PATCH([+-].*)? | |
# | |
# Parse the major, minor and patch versions | |
# out. | |
# You use it like this: |
const FullHeightPage = () => ( | |
<div> | |
Hello World! | |
<style global jsx>{` | |
html, | |
body, | |
body > div:first-child, | |
div#__next, | |
div#__next > div { | |
height: 100%; |
You probably arrived here because of a curt message in response to an issue you filed on a repo that I contribute to. Sorry about that (particularly if you filed the issue long ago and have been waiting patiently for a response). Let me explain:
I work on a lot of different open source projects. I really do like building software that makes other people's lives easier, but it's crazy time-consuming. One of the most time-consuming parts is responding to issues. A lot of OSS maintainers will bend over backwards to try and understand your specific problem and diagnose it, to the point of setting up new test projects, fussing around with different Node versions, reading the documentation for build tools that we don't use, debugging problems in third party dependencies that appear to be involved in the problem... and so on. I've personally spent hundreds of hours of my free time doing these sorts of things to try and help people out, because I want to be a responsible maintainer and I