igorcosta

📖 Managing dual repositories on GitHub

Managing multiple repositories that serve distinct but interconnected purposes can be a challenging task 😓. This scenario is common when an organization wishes to contribute to an open-source project 🌐 while also maintaining an internal space for private collaboration 🔒.

The challenge here lies in keeping these repositories in sync 🔄 without manual intervention, ensuring that changes made to one repository 📁 are accurately reflected in the other 📁.

In this step-by-step tutorial 📃, we'll walk through a use case where a customer wants to contribute to an open-source project 💻 and, at the same time, collaborate internally within their organization 🏢.

We will:

1. Changing the ownership of the existing repository. [Follow this steps](https://docs.github.com/en/enterprise-cloud@latest/account-and-profile/setting-up-and-managing-your-personal-account-on-gi

igorcosta

get_org_languages.py 🚀

Python script to get all the programming languages in a GitHub organization and return a total number of repos using the programming language.

Hard requirements: 🐍

• Make sure you know Python 3.0 or older.
• Make sure you have a GitHub Personal Access Token with the read:org and repo:status permissions. 🔐
• Install the Python dependencies:

igorcosta

Based on https://docs.getutm.app/guides/windows/

0. Get UTM for Mac - the App Store version is offered merely as a way to support the developers, since it's paid, but has the same features as the free build;
1. Obtain scripts that bootstrap an arm64 Windows 11 22H2 (I've chosen Windows Home edition and not Pro);
2. brew install aria2 cabextract wimlib cdrtools minacle/chntpw/chntpw;
3. cd into the directory extracted in step 1 and bash uup_download_macos.sh - this will produce an ISO;
4. In the UTM app, create a new “Virtualize” machine and mount the ISO file from the previous step;
5. Check “Install drivers and SPICE tools”;
6. Boot the VM and go through the Windows installer;
7. Boot the installed OS and finish the SPICE tools installer that should pop up by itself, then reboot the OS;

igorcosta

#!/bin/bash

# Make sure you change this script chmod to executable 

# Set your GitHub username and access token
USERNAME={REPLACE_ME}
ACCESS_TOKEN={REPLACE_ME}

# Set the path to the directory where you want to store your repositories
LOCAL_REPO_DIR=/path/to/your/local/repo/directory

igorcosta

One of the biggest issues with using a self hosted GitHub runner is that actions that require downloading large amounts of data will bottleneck at the network. [actions/cache][1] does not support locally caching objects and artifacts stored on GitHub's servers will require a lot of bandwidth to fetch on every job. We can, however, set up a content proxy using [Squid][2] with SSL bumping to locally cache requests from jobs.

Patching Squid

A major challenge is that [actions/cache][1] uses Azure storage APIs which makes HTTP range requests. While Squid supports range requests, it is not good at caching them. There is an option, range_offset_limit none which, according to the [documentation][3]:

A size of 'none' causes Squid to always fetch the object from the beginning so it may cache the result. (2.0 style)

However, after extensive debugging, I discovered that the feature does not work if the client closes the connection. When range_offset_limit is set, Squid will make a full request to the server,

igorcosta

Limitations in our products

Because the customer uses infrastructure as a code (IaC) into their pipelines using AWS CloudFormattion, they were used to the YAML format and the advanced features from the AWS schema and functionalities available, Actions YAML was simple to use and teach, however, introduced last year the workflow_dispatch allows customers to create workflows that are manually trigger with the option of input parameters. Our product supports only a limit of 10 inputs and throws an error, not allowing customer with multi-cloud environment setup more control for those manually trigger workflows.

We introduced a few options for the customer with the goal of continue maintaining the developer experience, interoperability, compliance and security and the ability to use the product in a multi-cloud environment.

Using commit message in JSON format

igorcosta

GitLab to GitHub Enterprise Cloud (GHEC) migration playbook

This playbook is a step-by-step guide to assist you with migration from GitLab to GitHub.com Enterprise Cloud GHEC.

Steps & Tasks	Description
Step One	Let's get ready for the migration. This step gives you an overview of what is required to start the migration process
Step Two	Creating the artefact to be imported on GitHub requires special access to the Enterprise Cloud Import tool. This step will help you understand what is required to get access to the tool.
Step Three	With the file ready to be imported, this step will guide you on how to connect and upload the file to your GitHub Enterprise Cloud instance.

igorcosta

#pip3 install joblib first

from joblib import Parallel, delayed
import time


start_time = time.time()

def BillionFuncJob(key):

igorcosta

package com.example.wear;

import android.app.Activity;
import android.hardware.Sensor;
import android.hardware.SensorEvent;
import android.hardware.SensorEventListener;
import android.hardware.SensorManager;
import android.os.Bundle;
import android.support.wearable.view.WatchViewStub;
import android.util.Log;

igorcosta

# Procedure is for Ubuntu 14.04 LTS.

# Using these guides:
# http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/
# https://turboflash.wordpress.com/2009/06/23/curl-adding-installing-trusting-new-self-signed-certificate/
# https://jamielinux.com/articles/2013/08/act-as-your-own-certificate-authority/

# Generate the root (GIVE IT A PASSWORD IF YOU'RE NOT AUTOMATING SIGNING!):
openssl genrsa -aes256 -out ca.key 2048
openssl req -new -x509 -days 7300 -key ca.key -sha256 -extensions v3_ca -out ca.crt