tailscale / github-action

A GitHub Action to connect your workflow to your Tailscale network.
BSD 3-Clause "New" or "Revised" License
566 stars 86 forks source link

tailscale does not turn on if we are using "container" within the github workflow #96

Open danield555 opened 11 months ago

danield555 commented 11 months ago

to reproduce, see the workflow example :

name: tailscale

on:
    push:
        branches:
            - main
    pull_request:
        branches:
            - '*'

jobs:
    build:
        runs-on: ubuntu-latest
        container: ubuntu:latest
        steps:
            - name: Check out code
              uses: actions/checkout@v4

            - name: install curl dependency
              run: apt-get update && apt-get install curl sudo -y

            - name: Tailscale Action
              uses: tailscale/github-action@v2
              with:
                oauth-client-id: ${{ secrets.TS_OAUTH_CLIENT_ID }}
                oauth-secret: ${{ secrets.TS_OAUTH_SECRET }}
                tags: tag:ci

            - name: check for hello.ts.net in netmap
              run:
                tailscale status | grep -q hello
DentonGentry commented 11 months ago

Running in userspace mode means that the other processes running in the Action would need to support SOCKS5 or HTTP proxies and set their ALL_PROXY or HTTP_PROXY to point to the localhost port where the tailscaled has been set to listen, like --socks5-server=localhost:1055 --outbound-http-proxy-listen=localhost:1055

https://tailscale.com/kb/1112/userspace-networking/

We focus on having the Action run in TUN mode because it makes all sockets-based applications in the GitHub runner work. Support for SOCKS5/HTTP_PROXY in apps isn't universal.

danield555 commented 11 months ago

as soon as I add the --tun=userspace-networking the tailscale works, but... I needed to add --exit-gateway="xx" to exit from a specific ip to a service, and the exit gateway is not taken into account when using networking mode ?

markstos commented 7 months ago

This relates to #113 about not working with curl being missing. That's another assumption that may not be true within a container, along with sudo possibly not being there either.