Posted on

A Dev Suppoort tool for GitHub

Every now and then, one may wish to have had a simple script to check out or
update all the github repos you have, at once, using a single command. 

This can be for the reason of backups, or simply, check out new ones that you don’t have etc,
or, keeping a local up-to-date copy of everything. 

Well, I wrote a similar little script some time back for BitBucket.
(http://emberlabs.tech/2023/05/08/easily-mirror-a-bitbucket-repo/)

This should work just fine on pretty much any Linux or Mac install (or similar with a bash). 

Nuf of the talk! Show me the code!! =D

#!/bin/bash
# GH Mass checkout. 
# V 1.0 - 2025-11-23 Spruce
# Prerequisites: curl and jq
# Place your GH PAT in ~/.gitpat (contents / read-only needed)
# Relies on SSH for cloning/pull, add your public key to GH. 

ORG="[Your ORG name here]"
PAT="[Your GH PAT]"
CDIR="$(pwd)"

if [ "${PAT}" == "" ] 
then
    if [ -e ~/.gitpat ] 
    then 
        PAT="$(grep github ~/.gitpat | head -1)"
    else
        echo "No PAT available."
		echo "Create a PAT (Profile -> Settings -> Developer settings -> PAT"
		echo "Select fine-grained,  account/org, and all repos, then select contents with read-only."
        exit 1
    fi
fi

function GetRepoLists {
    echo ""
    echo -n "Updating the repolists : "  
    rm -f repolist.*
    for page in $(seq 1 20) ; do
        echo -n "${page} "
        curl -s \
            -H "Accept: application/vnd.github+json" \
            -H "X-GitHub-Api-Version: 2022-11-28" \
            -H "Authorization: Bearer ${PAT}" \
            "https://api.github.com/orgs/${ORG}/repos?per_page=100&page=${page}" \
            | jq -r '.[].ssh_url' > repolist.${page}
        if [ ! -s "repolist.${page}" ]
        then
            rm -f "repolist.${page}"
            break
        fi
    done
    echo ""

    cat repolist.* > repolist
    rm -f repolist.*
}


function ClonePull {
    mkdir -p ${ORG}

    while IFS= read -r URL; do
        repo="${URL##*/}"
        repobase="${repo%.git}"
        if [ -e "${ORG}/${repobase}" ]
        then
            echo "Updating ${ORG}/${repobase}" 
            cd ${ORG}/${repobase}
            git pull
            cd ${CDIR}
        else
            echo "Cloning  ${URL}"
            cd ${ORG} 
            git clone ${URL}
        fi
    done < "./repolist"
}

function GitExec {
	GITCMD="$1"
	cd ${ORG}
	for repo in *
	do
		echo "Executing ${GITCMD} in ${ORG}/${repo}" 
		cd ${CDIR}/${ORG}/${repo}
		git ${GITCMD}
		cd ${CDIR}
    done 
}

# --- Actions -------------------------------------------------------

case "$1" in
    full)
        GetRepoLists
        ClonePull
        ;;
    pull)
        GitExec "pull"
        ;;
    fetch)
        GitExec "fetch"
        ;;
    *)
        echo "Usage:"
        echo " "
	echo "       full      Update existing and clone new repos."
        echo "       fetch     Execute a fetch on all existing repos."
	echo "       pull      Execute a pull on all existing repos."
    ;; 
esac

Njoy!!

Posted on

Some Language oddities

Let’s start with some the classics:

Our ever “friend” JavaScript
console.log("b" + "a" + +"a" + "a") ;
“baNaNa”? Really?

console.log( [] !== [] ) ;
.. evaluates to “true”? Really?? JS?
an empty array is absolutely truly different from, in values, shape, and form, from…  an empty array?

Then, Typescript?
function (a: any, b: any) any

Typescript: let’s enforce types on data and vars.
Dev: Nope!

 

 

Posted on

1PassMapper – updated.

Not too long ago, we published this article about the 1PassMapper.
( article: http://emberlabs.tech/2025/09/18/1passmapper )

Guess what?
It just got updated with a couple of new items to make it even more powerful!

We just added the flags -prefix <path> and -token <filename> .

The -prefix allows you to have the same build script prepend the source paths in the template, using a single template for all your environments, instead of multiple files, moving the prefix of the path into an argument.

In the template, you would use something like [[some.path.to.cred]],  and with the -prefix dev , the real path would be: [[dev.some.path.to.cred]].

Replace the `-prefix dev` with -prefix prod, and now, you would use the “prod” source path in your credentials file.

The -token <filename>` ?  – this is how you can easily switch from using the default 1Password token file to some other token file allowing you the use of multiple 1Password accounts for different needs.

Get your team onboard with keeping the creds out of the GIT!

Get your copy today – It’s free!
https://github.com/emberlabstech/1PassMapper

Njoy!!

 

Posted on

1PassMapper

Securing Your Development & Deployments with 1PassMapper

Source: https://github.com/emberlabstech/1PassMapper

At EmberLabs®, security has always been at the heart of how we design, build, and deploy software.
One recurring challenge for Dev/DevOps teams is keeping the security of credentials with the practical need for configuration during builds and deployments, while just going about doing their day to day work. 

Far too often, secrets end up hardcoded in Git repositories and code, CI/CD pipelines, or configuration files – creating risks that can later become costly breaches.

This is where 1PassMapper comes in.


Why 1PassMapper?

Modern development teams rely heavily on automation.
Whether you’re deploying Docker containers, Kubernetes workloads, or traditional servers, there is always a need to inject API keys, database passwords, and certificates at “runtime” or build of deployment.

The problem:

  • You want to keep your configuration templates versioned in Git.

  • You do not want to commit sensitive credentials.

  • You want to maintain credentials and settings in a single location, but used in many locations – Single update.
  • When credentials (or other data) rotate, you need builds to automatically reflect those changes.

  • You may need different credentials for different environments without duplicating templates.

1PassMapper solves this by bridging your templates and secure vaults (like 1Password).


How It Works

1PassMapper allows you to:

  • Define your configuration files as templates (with tags like [[sql.host]]).

  • Store credentials in a JSON object either locally or inside a 1Password vault item.

  • Automatically map placeholders in your templates to the correct secret or configuration values during your build process.

This means your Git repository contains only clean templates with placeholders, while the real secrets live securely in 1Password.

Example:

Template (sample-template.json):

{
    "item1": "[[sql.host]]",
    "item2": "[[sql.user]]",
    "item3": "[[sql.pass]]",
    "item4": "[[host.domain]]",
    "item5": "[[cred.UNKNOWN]]"
}
Credentials (in 1Password or a local JSON file):
{
  "sql": {
    "host": "some.domain",
    "port": "3306",
    "user": "root",
    "pass": "someAwesomePassword"
  },
  "host": {
    "domain": "myCoolDomain.com",
    "port": "443",
    "certKey": "certificate.key",
    "cert": "certificate.pem",
    "certpass": "myKeyPassword"
  }
Practical example – build from 1Password CICD/MySecretItem, 
1PassMapper -in sample-template.json -out config.json -vault CICD -item MySecretItem
or, using a local file:
1PassMapper -injson sampleJsonCreds.json -in sample-template.json -out config.json

Build output (config.json):

{
    "item1": "some.domain",
    "item2": "root",
    "item3": "someAwesomePassword",
    "item4": "myCoolDomain.com",
    "item5": "[[cred.UNKNOWN]]"
}
Your secrets never touch Git, and you can freely reuse the same template across environments.

Security Benefits

  • Eliminates hard-coded secrets from Git, Code in general, and possibly Docker images.

  • Centralizes credential storage in 1Password with audit trails and rotation policies.

  • Supports environment isolation (dev, staging, prod) with the same templates, using the Makefile or similar, to determine the template used.

  • Provides consistency across local builds and CI/CD pipelines, by using the same key for common items. 


Development Benefits

  • Less hassle: new developers pull templates without worrying about leaking secrets.
    Just map a key to a secret – it’s reusable!

  • Deduplication: Provides a way to use values, provided by by namespaces, leading to less duplication.
  • Flexibility: supports Json, Yaml, or any other textbased configuration formats, including code. 

  • Resilient pipelines: secrets update automatically when rotated in 1Password.

  • Portability: build in the cloud or locally with the same tooling.


Why EmberLabs® Built This

At EmberLabs®, we wanted a solution that was:

  • Lightweight and developer-friendly.

  • Flexible enough to handle multiple environments.

  • Strongly aligned with secure-by-design principles.

With 1PassMapper, we created a tool that is fast and simple, and integrates seamlessly into existing DevOps workflows,
with the aim to give teams confidence that their deployments are both secure and repeatable, and offers a way to reduce
configuration duplication as an added bonus. 


Summing it up.

In 2025, development speed can’t come at the cost of security. Seriously.
With 1PassMapper, teams can have both: secure credential management and streamlined deployments.

If your organization struggles with keeping secrets safe while maintaining efficient builds, this approach may change how you think about DevSecOps practices.

🔒 Secure your pipelines.
⚡ Accelerate your workflows.
✅ Standardize your deployments.

© EmberLabs® (BY-SA)

Enjoy!