hey nerds! i got a lovely email from GitHub this morning that their increasingly vibe-coded, barely-working Actions features are about to get more expensive (charging by the minute for something that notoriously spin-locks is a special flavor of shit sandwich).

i usually just use whatever i’m given at wherever i’m working. i do have a project that i maintain to parse Ollama Modelfiles tho: https://github.com/covercash2/modelfile and to be honest, Actions is the only solution i’ve ever used that came close to sparking joy, simply because it was easy to use and had tons of community mind-share (i’ve definitely heard horror stories and would never stake my business on it), but this price increase and all the other news around GitHub lately has got me side-eying self-hosting solutions for my git projects. Forgejo seems like the way to go for git hosting, but Actions in particular Just Works™️ for me, so i’m kind of dreading setting something up that will be yet another time sink/rabbit hole (just in time for the holidays! 🙃).

i can install most of my tooling with my language toolchain (read: rustup and cargo) which makes things fairly neat, but i just don’t have a sense for what people use outside of Jenkins and Actions.

i thought this community might have some insight beyond the LLM generated listicles that have blighted modern search results.

thanks in advance 🙏

  • Scrubbles@poptalk.scrubbles.tech
    link
    fedilink
    English
    arrow-up
    2
    ·
    6 hours ago

    Sure! I use Kaniko (Although I see now that it’s not maintained anymore). I’ll probably pull the image in locally to protect it…

    Kaniko does the Docker in Docker, and I found an action that I use, but it looks like that was taken down… Luckily I archived it! Make an action in Forgejo (I have an infrastructure group that I add public repos to for actions. So this one is called action-koniko-build and all it has is this action.yml file in it:

    name: Kaniko
    description: Build a container image using Kaniko
    inputs:
      Dockerfile:
        description: The Dockerfile to pass to Kaniko
        required: true
      image:
        description: Name and tag under which to upload the image
        required: true
      registry:
        description: Domain of the registry. Should be the same as the first path component of the tag.
        required: true
      username:
        description: Username for the container registry
        required: true
      password:
        description: Password for the container registry
        required: true
      context:
        description: Workspace for the build
        required: true
    runs:
      using: docker
      image: docker://gcr.io/kaniko-project/executor:debug
      entrypoint: /bin/sh
      args:
        - -c
        - |
          mkdir -p /kaniko/.docker
          echo '{"auths":{"${{ inputs.registry }}":{"auth":"'$(printf "%s:%s" "${{ inputs.username }}" "${{ inputs.password }}" | base64 | tr -d '\n')'"}}}' > /kaniko/.docker/config.json
          echo Config file follows!
          cat /kaniko/.docker/config.json
          /kaniko/executor --insecure --dockerfile ${{ inputs.Dockerfile }} --destination ${{ inputs.image }} --context dir://${{ inputs.context }}     
    

    Then, you can use it directly like:

    name: Build and Deploy Docker Image
    
    on:
      push:
        branches:
          - main
      workflow_dispatch:
    
    jobs:
      build:
        runs-on: docker
    
        steps:
        # Checkout the repository
        - name: Checkout code
          uses: actions/checkout@v3
    
        - name: Get current date # This is just how I label my containers, do whatever you prefer
          id: date
          run: echo "::set-output name=date::$(date '+%Y%m%d-%H%M')"
    
        - uses:  path.to.your.forgejo.instance:port/infrastructure/action-koniko-build@main # This is what I said above, it references your infrastructure action, on the main branch
          with:
            Dockerfile: cluster/charts/auth/operator/Dockerfile
            image: path.to.your.forgejo.instance:port/group/repo:${{ steps.date.outputs.date }}
            registry: path.to.your.forgejo.instance:port/v1
            username: ${{ env.GITHUB_ACTOR }}
            password: ${{ secrets.RUNNER_TOKEN }} # I haven't found a good secret option that works well, I should see if they have fixed the built-in token
            context: ${{ env.GITHUB_WORKSPACE }}
    

    I run my runners in Kubernetes in the same cluster as my forgejo instance, so this all hooks up pretty easy. Lmk if you want to see that at all if it’s relevant. The big thing is that you’ll need to have them be Privileged, and there’s some complicated stuff where you need to run both the runner and the “dind” container together.

    • felbane@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      5 hours ago

      Thanks for the write-up! I’ve been trying and failing to do DOOD and POOP runners via forgejo, but I haven’t had the time or energy to really dig in and figure out the issue. At this point I just want something to work so I’ll give your setup a try 😎