For everyone here, this is true, and I’d recommend buying a couple drives for quick replacements. If you don’t you’re gambling that 1) a replacement drive will be available and 2) that it will be affordable.

Keep a few spares lying around while we get through the ebbs and flows of the market. As K said, a person is smart, people are dumb and panicky. If ssd and storage prices rise, people panic and our hdds will rise too.

Prep now and thank yourself later.

I see there’s still a pro version though, that’s how Insomnia started and features have slowly been leeching to “pro only”, is that a worry with this one?

Bruno looks almost exactly the same! Thank you!

This looks really nice! Thank you!

Hello fellow midwesterner!

Exactly this. People here mass downvote but I personally find AI to be extremely useful… To do things I already know how to do but don’t have the time for. I don’t trust it to do things I can’t spot the errors in

I’ve literally gotten jobs because of my homelabbing. Being able to talk about how I run services and why I enjoy them has helped more than most of my professional work

It’s the same for me. It’s been more noticeable doing everyday tasks than it has been for gaming.

They killed off openvpn support a few years ago and am glad I did. They don’t care about power users, so they don’t care about my money either. Good riddance

Of course! Let me know how you run your containers and I may be able to help on that side too

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.

some dude (or dudette) is living rent free in this guy’s mind

But you are charged for it.

Forgejo runners are great! I found some simple actions to do docker in docker and now build all my images with them!

I picked up a few today from smaller online stores before they realized. Will have to keep the servers running somehow

Good note, and good callout, we should always call out these things.

But yes if you’re self hosting and you both have a public facing instance and allow open registration, you are a much much braver person than I.

Okay that changes things. If they turned off these guardrails than that was on them, never blindly trust an LLM like that

Oh my god really? Cursor explicitly asks you each command and could only do this in “yolo” mode. Not having these guardrails is insane

Okay that makes so much sense, because I knew I had calling before in Element but they wanted me to set up all this extra stuff. Is it still a thing to do the plugin?

Wait there’s a jitsi plugin?