iiinova — where your digital self keeps evolving

George MacRorie @georgemac.bsky.social · 13/06/2026

👏 put the fascists on the train home 👏 we 👏 dont 👏 want 👏 them 👏 here 👏 #brighton

050 0

George MacRorie @georgemac.bsky.social · 25/07/2025

Morty doesn’t know when you took this photo of him. But he approves all the same. That’s a good pack 🐾

110 0

George MacRorie @georgemac.bsky.social · 09/04/2025

Trump administration is giving the Lettuce a run for its money.

Always sunny in Philadelphia gif of Mac, Charlie and frank saying art of the deal.

030 0

George MacRorie @georgemac.bsky.social · 02/03/2025

Currently enjoying a little bit of mountain peace before starting the next role. My legs are zapped and it’s only day three. #grandmassif

170 0

George MacRorie @georgemac.bsky.social · 17/01/2025

This photo of Morty from this week on walks in the snow was just too good not to share.

190 0

George MacRorie @georgemac.bsky.social · 07/12/2024

This new, fine grained history can be leveraged to reverse just the operations necessary to rollback the particular pipelines relevant changes. It also means, that the history view per phase, only contains the points in Git history that effected our particular application.

100 0

George MacRorie @georgemac.bsky.social · 07/12/2024

So Glu goes a step further and builds per phase history using your code. When you implement a Glu pipeline, you explain (in Go) how to marshall what changes to and from the filesystem per phase. When commits come in, Glu runs this code per phase to extract the relevant changes and log them itself.

100 0

George MacRorie @georgemac.bsky.social · 07/12/2024

But this is just Git history right? That's the point of putting it in Git in the first place. True, and Git and it's commits remain the source of truth for Glu. However, Git's history contains entries for all my applications, and a single commit could touch multiple of them in our pipeline.

100 0

George MacRorie @georgemac.bsky.social · 07/12/2024

Yesterday @markphelps.github.io and I finished our first MVP of history and rollback capabilities in Glu. Now each phase in Glu has its own relevant and isolated history of versions that can be explored and when needed, rolled back to. #buildinpublic #golang #gitops 🧵

132 0

George MacRorie @georgemac.bsky.social · 06/12/2024

Also, notice that our iterator does a range on our channel of entries. This will run until this channel is closed. We close this channel in a defer in the goroutine which calls ascend/descend. This ensures both conditions "btree is exhausted" and "iterator returned early" coordinate and cleanup.

110 0

George MacRorie @georgemac.bsky.social · 06/12/2024

The stop channel is going to allow our iterator to signal an early exit when the new style iterator recieves a false when calling yield. This happens when a for range over the iterator returns early (e.g. in a break or return). Notice we close this channel in a defer in our iterator sequence.

110 0

George MacRorie @georgemac.bsky.social · 06/12/2024

Now we can start our Ascend / Descend old style iterator in a goroutine. Remember these take a function which operates on each entry in the tree. So, we're going to use this opportunity to send on our channel. We use select in our function to switch between our send operation or a receive on stop.

110 0

George MacRorie @georgemac.bsky.social · 06/12/2024

We're going to call Ascend / Descend in their own goroutine as we dont want to block returning an iterator. We're going to use a channel (well two, we will come to that) for passing our entries from old iterator to the new one. A buffer of zero ensures we synchronize our sender and receiver.

110 0

George MacRorie @georgemac.bsky.social · 06/12/2024

We need to be able to control iteration, yielding to range at our own discretion with the iter package. However, btree's style of iteration enters a feeding loop when we call Ascend or Descend. So how can we go about coordinating these two styles together? Enter goroutines and unbuffered channels.

110 0

George MacRorie @georgemac.bsky.social · 06/12/2024

On initial glance, this looks a looks a lot like the new iterator style in Go, which also involves a function for handling individual entries in the collection. However, the contract is actually the inverse. With the iterator package in Go, we are given a function to yield to.

110 0

George MacRorie @georgemac.bsky.social · 06/12/2024

The package in question is Google's BTree implementation. pkg.go.dev/github.com/g... This package long predates the new iterator style and exposes its own methods Ascend and Descend for iteration in a particular direction. These methods take a function returning a boolean to signal when to stop.

110 0

George MacRorie @georgemac.bsky.social · 06/12/2024

I am doing silly things with #golang iterators again. So thought I would share in the hope it is helpful, or maybe someone will show me a better way. This time I have a collection type, which exposes its own abstraction for iterating over its contents. Instead, I want it to use the iter package. 🧵

250 0

George MacRorie @georgemac.bsky.social · 05/12/2024

It's one of those days go get -u ./... (everywhere) #golang

020 0

George MacRorie @georgemac.bsky.social · 04/12/2024

Today in Glu world we added support for built-in history. History is tracked on a per pipeline and phase basis and available in the UI on main. We also added API support for rollbacks (UI is under development): github.com/get-glu/glu/... Tomorrow I will have a video! #buildinpublic #golang

020 0

George MacRorie @georgemac.bsky.social · 03/12/2024

Big change going into Glu today with only minor face value. A lot of the core types are moving around. The biggest being the move from phases and sources, to phases and edges. The concept of promotion in Glu is a now a concern for edges. #buildinpublic #golang github.com/get-glu/glu/...

110 0

George MacRorie @georgemac.bsky.social · 29/11/2024

I spent today building per pipeline+phase history feature into github.com/get-glu/glu. It allows for tracking meaningful history per app + per env described in a config repo. For reasons (I just love it), I am starting with bbolt as a backend (shoutout @benbjohnson.bsky.social). #golang #gitops

120 0

George MacRorie @georgemac.bsky.social · 28/11/2024

Been working on some small touches to the feedback in the UI for github.com/get-glu/glu today. Now it little success toast will link you to any generated PRs (if you have proposals enabled). #gitops #deployments #cicd #golang #buildinpublic

231 0

George MacRorie @georgemac.bsky.social · 23/11/2024

Oh yeah and this is Stu. He is just happy he didn't become Glu. No horses were harmed in the making of this Glu factory.

220 0

George MacRorie @georgemac.bsky.social · 23/11/2024

The Glu library exposes an api for building binaries which can run as one shot pipeline operators, or as a long running server daemon. As a daemon it exposes an API, based on the pipelines and phases you describe in Go. Additionally, you can go get our prebuilt UI and include it at compile time.

110 0

George MacRorie @georgemac.bsky.social · 23/11/2024

Our initial goal has been small, and that is to solve some the problems described in this thread. Follow an #OCI image tag for new versions, update a target repo when it changes target and also to have the ability to manually promote a version from one environment to the next.

An image containing a code editor with some glu code demonstrating an OCI phase and a staging phase in a pipeline.

110 0

George MacRorie @georgemac.bsky.social · 23/11/2024

At the end of adding this automation, you're also going to want to understand the state it is all in. Because you're quickly going to want answers to questions like "is the latest version of my app foo deployed to dev?", "why hasn't version N reached production yet?" and so on.

120 0

George MacRorie @georgemac.bsky.social · 23/11/2024

Remember that our goal is continuous delivery, so we also want automation to trigger and write these immutable digests into version control the moment a new version of our code is deemed ready to be deployed.

130 0

George MacRorie @georgemac.bsky.social · 23/11/2024

In order for a single commit in version control to represent a fully reproducible moment in your systems history; you're going to want it to contain specific, immutable versions of the software artefacts being deployed.

110 0

George MacRorie @georgemac.bsky.social · 23/11/2024

If you've ever put a #GitOps pipeline together, you might might be familiar with the missing pieces. The available #CICD tools are excellent for laying that runway to your desired environment. However, the friction comes the moment you have more than one environment.

A diagram showing three nodes in a graph with edges between them. They represent a source artefact through through two target deployment environments.

110 0

George MacRorie @georgemac.bsky.social · 23/11/2024

Been prototyping a tool with @notmarkphelps.bsky.social recently around orchestrating software delivery across multiple environments. We chose to model our solution as a framework in #golang with an optional embedded #typescript / #react UI, as we wanted to ditch our yaml/bash GitHub action woes.

A screenshot of the Glu UI dashboard showing a pipeline for a billing application deploying to a staging and a production environment.

340 0

George MacRorie @georgemac.bsky.social · 28/05/2024

Yesterday we released reverst v0.2.0. The highlight being it builds a new CLI which can proxy services on your local network through a reverst tunnel group. github.com/flipt-io/rev... #golang

Image of reverst CLI in the terminal serving http from a local port (8080).

020 0