Comment on Immich 2.1 Released with Better Slideshow Shuffle, New Notifications

• JASN_DE@feddit.org ⁨4⁩ ⁨months⁩ ago

  Which isn’t a great idea with all the breaking changes. I’d assume it gets better after v2, but still.

  source

  • GraveyardOrbit@lemmy.zip ⁨4⁩ ⁨months⁩ ago

    [deleted]

    source

    • skilltheamps@feddit.org ⁨4⁩ ⁨months⁩ ago

      That’s what I thought, but last time I looked I only saw a “release” tag, no “v2” tag. Did I miss something?

      source
  • LastYearsIrritant@sopuli.xyz ⁨4⁩ ⁨months⁩ ago

    I automate my upgrades, but I also automate my backups, and monitoring.

    If an upgrade breaks something, my health monitor lets me know and I can roll back to the previous day.

    source

    • TrumpetX@programming.dev ⁨4⁩ ⁨months⁩ ago

      This is the way

      source
    • BackgrndNoize@lemmy.world ⁨3⁩ ⁨months⁩ ago

      What tools do you use for the monitoring, backup and rollback?

      source

      • LastYearsIrritant@sopuli.xyz ⁨3⁩ ⁨months⁩ ago

        I use rsync to backup, I can delete and restore the whole drive if i want at any time.

        I use watchtower to keep things updated. If you schedule the rsync and watchtower correctly, you can get the backup done before the upgrade and there’s basically no lost data with the rollback.

        I use uptime Kuma for monitoring, and it shoots me an email with details on what failed.

        source

        • -> View More Comments
  • saddlebag@lemmy.world ⁨4⁩ ⁨months⁩ ago

    I’ve been doing this in my kubernetes cluster since immich was less than v1.49.0 (that’s the earliest I can find but it’s been over 4 years).

    Your comment could have been more constructive: something like “this is really cool, just be sure you don’t auto merge PRs without reading the patch notes. Learn about the process before you roll this out to your mission critical systems!”

    This is a learning opportunity (possibly even for you). Show others how to do things well and the whole community can benefit.

    source

    • Tywele@lemmy.dbzer0.com ⁨4⁩ ⁨months⁩ ago

      You sound condescending af.

      THis is a learning opportunity (possibly even for you)

      source

      • elvith@feddit.org ⁨4⁩ ⁨months⁩ ago

        Hey everyone has a learning opportunity. Some even have a separate production system!

        source
      • saddlebag@lemmy.world ⁨4⁩ ⁨months⁩ ago

        Did you learn anything?

        source
  • Fmstrat@lemmy.world ⁨3⁩ ⁨months⁩ ago

    The 2.0 release resolves a large amount of technical debt and shifts the focus toward compatibility and easier upgrades.

    source
• cRazi_man@europe.pub ⁨4⁩ ⁨months⁩ ago

  This looks a lot more complicated that Watchtower. Is this something different or add other functionality?

  source

  • saddlebag@lemmy.world ⁨3⁩ ⁨months⁩ ago

    I’m not familiar with Watchtower, I assume it will restart the container/stack if a new image is found. The biggest difference is that an edit to the git repo causing the container to be redeployed. This means the git repo becomes the source of truth and its possible to redeploy even when config changes get merged.

    source
• nfreak@lemmy.ml ⁨4⁩ ⁨months⁩ ago

  I’ve been running this setup for a few months now and haven’t looked back. Works super well, and essentially acts as an approval process for letting a container update or not.

  The author also recently added a followup article to this one for using Forgejo instead, made migrating the setup super easy.

  source
• JC1@lemmy.ca ⁨3⁩ ⁨months⁩ ago

  Why this complicated setup? Komodo handles auto update by itself. It also update the whole stack at once, so no shutdown of the BD while the app stays up. Just have 2 checkboxes to tick.

  The less stuff the better, it’s essential in case you have a failure. I only have to redeploy komodo, then all my stacks will be ready to get back online. I even removed watchtower.

  source