Skilled Teleportation

Goal - provide sensible defaults to use actions-sync on GitHub Enterprise Server when you're stuck with manually syncing Actions from GitHub.com into your server environment due to no network connectivity.

Note

There's a much easier, pain-free, and overall much better way to manage access to Actions using GitHub Connect.

Directions

You have two paths here, a hard one and a slightly harder one. Either way, you'll need a personal access token that can create organizations and write to all of the synced organizations (like actions or github on GHES).

The hard way

Create a new repository in GitHub.com, then (optionally) create an extra-actions.txt file to suit your company's needs. Create a workflow file in .github/workflows/skills.yml, example below.

name: Bundle GitHub Actions to sync

on:
  workflow_dispatch: # run on demand

jobs:
  create-archive:
    runs-on: ubuntu-latest # use the GitHub hosted runners
    steps:
      - name: Create the latest archive
        uses: some-natalie/skilled-teleportation@v2
        with:
          list_file: extra-actions.txt

Run the workflow and then download the latest artifact, like shown below:

The latest version of actions-sync is in there, as is the script teleport-push.sh. Examine/scan/etc everything in the zip file, fling it to the other side where your GHES instance is, then run the script as follows:

./teleport-push.sh "https://github.yourcompany.com" "SOME-GITHUB-TOKEN"

The slightly harder way

1. Download actions-sync on the machine that pulls from GitHub.com and the machine that pushes into GHES.
2. Create a list of Actions to sync over. This Action just pulls over everything in github.com/skills, plus dependencies defined in skills-dependencies.txt and anything extra in extra-actions.txt. You can use the teleport-pull.sh script to do this if you'd like.
3. Tarball the whole thing up.
4. Untar it on the other side, then push the Actions into GHES. You can use the teleport-push.sh script to do this if you'd like.
5. If needed, change each repo that needs to be a template (such as the Skills repositories).

But why though?

There's a couple reasons.

1. skills.github.com is cool and, if you have self-hosted Actions runners with the ubuntu-latest label and the appropriate software installed on them, your on-premises users can have some neat self-paced training too.
2. Provide some sensible defaults to what can/should be synced from GitHub.com into your GHES installation.
3. Provide a framework to add more things to sync over.
4. I wanted to pick apart on-premises Actions without using GitHub Connect a little bit more.
5. Highlight how much easier this is using GitHub Connect instead. ❤️

CodeQL

Don't use this for syncing CodeQL. There's another tool specifically for that called codeql-action-sync-tool. It's not included in this Action by default because it also grabs the binary assets for CodeQL which adds a couple GBs to the archive.