jonico

# Replace the string "Hyrule" with your search pattern - only run on backup system - will take a LOOOONG time to run through
ghe-console -y <<'ENDSCRIPT'
  Repository.find_each do |repository|
    if repository.active && !repository.empty? then
      host,path = GitHub::Routing.lookup_route(repository.nwo)
        puts "Processing repo #{repository.nwo} ..."
        refs=`git --git-dir=#{path} rev-list --branches --tags | sort | uniq`
        refs.each_line do |ref|
          if system("git --git-dir=#{path} grep 'Hyrule' #{ref}")
            puts "Found pattern in ref #{ref} in repo #{repository.nwo}: "

jonico

apiVersion: v1
items:
- apiVersion: v1
  kind: Pod
  metadata:
    creationTimestamp: "2021-04-29T15:09:09Z"
    labels:
      pod-template-hash: 65f67dcb66
      runner-deployment-name: actions-runner-deployment-epona
      runner-template-hash: 6788f4694c

jonico

#!/usr/bin/bash
cd
mkdir -p /tmp/actions
git clone https://github.com/github/platform-samples.git
sdk install groovy
cd platform-samples/api/groovy/
groovy ListReposInOrg.groovy -t $GH_PUBLIC actions > ~/repo-list

cd
wget https://github.com/actions/actions-sync/releases/download/v202009231612/gh_202009231612_linux_amd64.tar.gz 

jonico

# copy Azure bloc storage files to S3 buckets
#
# Usage:
#   ./copy-azure-blob-storage-to-s3.sh <blob storage container> <s3 bucket>
#
# Example:
#   ./copy-azure-blob-storage-to-s3.sh my-container s3://my-bucket
#
# Note:
#   This script requires a working Azure CLI.

jonico

#!/bin/sh

# shell script that waits for a PlanetScale branch to be ready for use and increases retry times exponentially

#  usage: wait-for-ps-branch-readiness.sh <db name> <branch name> <max retries>

function wait_for_branch_readiness {
    local retries=$1
    local db=$2
    local branch=$3

jonico

PLANETSCALE_DB=brandnewdb
PLANETSCALE_BRANCH=mybranch
PLANETSCALE_ORG=jonico
PLANETSCALE_SERVICE_TOKEN=pscale_tkn_loCzIH7NktDK-GWJ71eX97Qr5D3a9iEO_pgHCSHUtw  
PLANETSCALE_SERVICE_TOKEN_NAME=69xrlIwgs4ms

jonico

MySQL on RDS configured for import to PlanetScale example

This folder contains an example Terraform configuration that deploys a MySQL database - using RDS in an Amazon Web Services (AWS) account - that is properly configured for PlanetScale's DB import feature.

It will make sure that the RDS database has the binlog exposed, gtid-mode set to ON and is using ROW-based replication. All these are pre-requisites for imports to work without zero downtime.

If you are going to write a lot of data in your database in a very short amount of time, don't forget the only manual step after the Terraform setup.

jonico

Scripts to determine PostgreSQL database size and rows processed

Differences between PostgreSQL and MySQL storage format and why this matters for billing estimations

tl;dr Rows processed numbers between Postgres and MySQL and database size may differ due to different index and row storage

PostgreSQL and MySQL are both relational databases with strong transactional capabilities. The way their storage engines store rows and corresponding indexes and how those indexes are used during queries differs significantly though. Check out this article from Uber Engineering for the technical details behind those differences.

Due to those index and row storage format differences, any numbers about rows read / written and database size from PostgreSQL will differ from the numbers you can expect once migrated to MySQL. If you are using similar indexes for your queries, the numbers should be pretty similar but depending on your exact queries and read/write pa

jonico

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext, SparkConf
from awsglue.context import GlueContext
from awsglue.job import Job
import time
from pyspark.sql.types import StructType, StructField, IntegerType, StringType

sc = SparkContext()

jonico

Docker compose files for temporal.io with external MySQL databases for temporal and temporal_visibility tables (using PlanetScale as example)

As the docker-compose files 👇 are using PlanetScale's MySQL-compatible Vitess database as an example, each database (temporal and temporal_internal) use different keyspaces and connection strings. Unfortunately, temporalio/auto-setup does not seem to support multiple connection strings for database creation and schema updates (using temporal-sql-tool), so the following commands would need to be run manually before starting up docker-compose:

./temporal-sql-tool --ep $TEMPORAL_PSCALE_HOSTSTRING --user $TEMPORAL_PSCALE_USER --tls  --password $TEMPORAL_PASSWORD-p 3306 --plugin mysql --db temporal setup-schema -v 0.0
./temporal-sql-tool --ep $TEMPORAL_PSCALE_HOSTSTRING --user $TEMPORAL_PSCALE_USER --tls  --password $TEMPORAL_PASSWORD-p 3306 --plugin mysql --db temporal update-schema -d ./schema/mysql/v57/temporal/versioned
./temporal