dave/site
1
0
Fork 0
mirror of https://github.com/davegallant/davegallant.github.io.git synced 2025-08-07 00:58:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

deploy: eb1136bf90

Browse Source
This commit is contained in:
davegallant
2024-02-10 15:55:45 +00:00
parent e1968d56b0
commit 3f65793c98
70 changed files with 73 additions and 73 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
js/flexsearch.78e4ca91e25c321a5aacc8c9c6f132977ccb568e94d7bb3b318f06ca2215f4cc949190b8f89a7569209f1a338d4ab302886d31a022df099f8d8eec5bcddad906.js → js/flexsearch.5af4d39e6753b3c5a1b4b0634ad10c51e9131b6080e5b3990b53a051c6847f92f3eb6002634e7f524df95cbebc1e2d3e7efaa3e9a7af41c33276c642e6e975f2.js
View File

@@ -5,8 +5,8 @@ Gitea Actions# Gitea Actions have made it into the 1.19.0 release. This feature
So what are they? If you’ve ever used GitHub Actions (and if you’re reading this, I imagine you have), these will look familiar. Gitea Actions essentially enable the ability to run github workflows on gitea. Workflows between gitea and github are not completely interopable, but a lot of the same workflow syntax is already compatible on gitea. You can find a documented list of unsupported workflows syntax.
Actions work by using a custom fork of nekos/act. Workflows run in a new container for every job. If you specify an action such as actions/checkout@v4, it defaults to downloading the scripts from github.com. To avoid internet egress, you could always clone the required actions to your local gitea instance.
Actions (gitea’s implementation) has me excited because it makes spinning up a network-isolated environment for workflow automation incredibly simple.
Integration with Tailscale# 2024-02-10: I had originally written this post to include Tailscale-Traefik Proxy Integration, but have since removed it in favour of Tailscale Serve and Funnel after learning from this example. This simplifies the setup and reduces the number of moving parts.
So how does Tailscale help here? Well, more recently I’ve been exposing my self-hosted services using Tailscale Serve and Funnel. This allows for a nice looking dns name (i.e. gitea.my-tailnet-name.ts.net), automatic tls certificate management, and optionally allowing the address to be publically accessible (using Funnel).
Integration with Tailscale# 2024-02-10: I had originally written this post to include Tailscale-Traefik Proxy Integration, but have since removed it in favour of Tailscale Serve after learning from this example. This simplifies the setup and reduces the number of moving parts.
So how does Tailscale help here? Well, more recently I’ve been exposing my self-hosted services using Tailscale Serve. This allows for a nice looking dns name (i.e. gitea.my-tailnet-name.ts.net), automatic tls certificate management, and optionally allowing the address to be publically accessible (by using Funnel).
Deploying Gitea, Traefik, and Tailscale# In my case, the following is already set up:
docker-compose is installed tailscale magic dns is enabled My preferred approach to deploying code in a homelab environment is with docker compose. I have deployed this in a LXC on Proxmox. You could run this on a virtual machine or a physical host as well.
The docker-compose.yaml file looks like: