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
        ·
        7 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
          ·
          6 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 😎