(Temporary) Project URL: github.com/lwbt/ts_build_test
💡
|
This might be a good introduction to GitHub Actions.The entire functionality here is just one GitHub Actions Workflow file. Read mode about it here. |
Provide automated builds of Tailscale as described in KB: Small Tailscale for embedded devices.
-
Building a combined binary of
tailscale
andtailscaled
-
Using the build option
--extra-small
-
Compressing the binary with UPX
|
Self-Update does not work with these builds.
Your can run the updater script with |
On official builds you can use tailscale update
to do a self-update, or even better Tailscale can do it for you with auto-updates.
Another popular program that uses self-updates is Syncthing, and it looks not too complicated: Update → URL.
Tailscale: runUpdate → Update → NewUpdater → Arguments.PkgsAddr → pkgs.tailscale.com. I think the updates are signed and will be verified, however I was able to modify the URL and create binaries with (broken) modified URLs.
At the moment, I’m not sure if self-updates can be implemented without touching more than just the URL in the code base. It would be nice to have, but doing such kinds of patches opens the door to do other sketchy things.
ℹ️
|
Just a quick test with
|
-
Billing Summary — Pipeline minutes and packages
-
Spending Limits — By default it should have a spending limit of 0, so you will not get billed but the functionalities will stop working when exceeding a limit. I have to figure out by myself how much on an impact this has, a I currently interpret it, I won’t hit the monthly pipeline minutes limit and outgoing data transfer for public packages seems to be free?
Pipeline consumption:
-
You can run the check every hour which takes about 30 seconds
-
If a build is created it will take about a total of 7 minutes, 2 minutes per architecture, and you will be "billed" 7 minutes, which means you will have 7 minutes left to use this month
If you clone the repository and run the workflow on your account, you will receive email from GitHub when a new release was created. You will also see that, while the cron definition says run every hour at 00 Minutes, that a runner will sometimes start and complete a few minutes later.
Here are the basic individual steps if you don’t want to fork:
# Login to GitHub (necessary on the first run)
gh auth login -h github.com -p HTTPS -w
# Create a new repo on GitHub
REPO="ts_build_test"
gh repo create ${REPO} --private
# Verify that the new repo exists
gh repo list
# TODO
# Do a git clone of the new repo here? GH already gives you the URL.
# Create folder structure for workflows
mkdir -pv .github/workflows
# TODO
# Do a git push of the new repo here?
Setting → Actions → General → Workflow permissions → "Read and write permissions" (default: "Read repository contents and packages permissions")
OWNER="lwbt"
REPO="ts_build_test"
gh api \
--method PUT \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
/repos/${OWNER}/${REPO}/actions/permissions/workflow \
-f default_workflow_permissions='write'