Mismatch between Docker latest image version and web release

[rlue]

First off, thanks for an amazing utility.

It looks like the latest tag of this Docker image was pushed to hub.docker.com on July 8, 2023, and is for version 4.2.3. Based on the GitHub releases page, it appears that the actual latest release of LinkStack is 4.8.4. Here is the update page I am presented with on a fresh deployment of LinkStack:

[lastsamurai26]

The problem is that the version is stored directly in the image, unfortunately we are missing a Docker programmer who can do this. We have already tried to do this via Curl so that he always gets the latest version from Git and we only have to adjust the Linux version etc. but we can't do that

[rlue]

Maybe I am misunderstanding, but it sounds like you want to be able to release LinkStack on Docker once and have it stay up-to-date forever. So at the risk of overexplaining—

Yes, a given docker image will always correspond to a fixed version of LinkStack, and you should push and tag a new image each time you release a new version. Keeping latest up-to-date is a matter of updating that tag to point to the latest numeric release(s), not configuring the image or Dockerfile to grab the latest version. In other words, releasing an app on Docker is not a one-and-done kind of thing, but rather part of its ongoing release cycle.

The best approach here would be to add a step to your automated release pipeline that builds a new Docker image and pushes it to Docker Hub with each version bump.

To take it a step further, I think the easier thing to do would be to not have a separate linkstack-docker repo at all, but rather to place the Dockerfile in the root of the Linkstack repo. That way, rather than having the Dockerfile pull LinkStack from GitHub, you could simply copy the files into the image directly from the filesystem.

[lastsamurai26]

On Docker hub you can see what I mean
ADD file:1da756d12551a0e3e793e02ef87432d69d4968937bd11bed0af215db19dd94cd in /

at that time the file (4.2.3) was provided in the images, and we don't want that anymore, actually it should load the last image (linkstack itself) from Git so that we only need to push a new image if the software in the container changes.
However, as I said, we are missing a Docker programmer.

i will talk to our main dev

[rlue]

On Docker hub you can see what I mean
ADD file:...

at that time the file (4.2.3) was provided in the images,

Sorry, I don't think that's quite correct.

ADD file:1da756d12551a0e3e793e02ef87432d69d4968937bd11bed0af215db19dd94cd in /

This line is actually from the parent Docker image alpine:3.18.2 that linkstack is based off of. Where the Dockerfile actually copies in linkstack into the image is here, on L40 of this repo's Dockerfile from July 2023. You can see that it copies the linkstack directory to htdocs/.

It's true that the Dockerfile is copying a file directly from the filesystem rather than fetching it from git. But it is not true that it is always copying in a fixed version of linkstack; rather, it just copies files the current working directory (aka your build context). If you modify the contents of the linkstack directory and run docker build again, you should get a different image. That's why it's advisable to keep the Dockerfile in the main linkstack repo itself, rather than maintaining a separate repo for it.

and we don't want that anymore, actually it should load the last image (linkstack itself) from Git so that we only need to push a new image if the software in the container changes.

If your Dockerfile always pulls the latest release from GitHub, then it can only build images for the current latest release. But if it copies from the current working directory instead, then you have the flexibility to make some experimental changes, run docker build, and get an image with those experimental changes included. (Obviously, you would not push those experimental changes to Docker Hub, but this flow is really helpful for verification purposes.)

I might still be misunderstanding, but I don't think you need to expand your staff for this. I think you could just move the contents of this repo to a subdirectory of your main repo, change COPY linkstack htdocs/ to COPY . htdocs/linkstack/, and then just

$ git checkout <release-tag>
$ docker build -t linkstackorg/linkstack:<version> -t linkstackorg/linkstack:latest --push .

[YamiDoesDev]

I didn't dive deep into the image yet, but all in all I'd agree to what @rlue said.
It shouldn't be much of a hassle to do and also for a single image another repo doesn't make much sense, rather just more work.

I am kind of here to check in, whether this will be worked on soon, as I am currently trying to figure out a way to get Linkstack running on our cute little k8s cluster.
I respect the time of all devs and thereby def would try to help in this matter, if I know, it doesn't stay left on read for months and even though I'd have to fix my docker image knowledge a bit.

(I really don't want Linktree to win in my org)

[YamiDoesDev]

Ok, I took a deeper look (for a few hours now because of a misunderstanding).
Apparently the Dockerfile is missing a RUN ln -s /usr/bin/php82 /usr/bin/php line, so It can execute php at some place.

@lastsamurai26 How about moving this repo into the other one, building a pipeline for automatic image build and push to Dockerhub? As I am pretty much on the fence timewise, I am willing to help by creating a Pull Request, if I get an answer pretty soon. Otherwise, I have to resort to building my own image on a private registry.

[lastsamurai26]

@lastsamurai26 How about moving this repo into the other one, building a pipeline for automatic image build and push to Dockerhub? As I am pretty much on the fence timewise, I am willing to help by creating a Pull Request, if I get an answer pretty soon. Otherwise, I have to resort to building my own image on a private registry.

I will talk to our main Dev.

[YamiDoesDev]

Been 5 days since, hm.

I'd offer you, the main Dev and whoever to look at the fork on my profile. Main changes are in:

• /.github/workflows/release.yml
  • added auto release on every new tag push
  • removed main Dev's token (GitHub Actions provides its own)
  • added a pipeline for building and pushing the image on Docker-Hub to currently used and last tag (see provided picture)
• /docker/
  • basically moved this entire repo in that directory
  • marked in the comments how I was able to build the image using curl (but don't plan on using those lines)

I need information about whether a private runner was used or not. If a public runner was used, Ubuntu20.04 is not supported anymore and needs to be updated to at least Ubuntu22.04 or rather Ubuntu24.04. In my case (24.04) php8.2 was not available, so I had to use php8.3 at least for executing composer. I'd recommend to check, if the software runs on 8.3, then it's all fine.

It's all kinda rudimentary and dirty at the moment. If the questions above are answered, and you're fine with the provided files, I'd create a clean fork and make a pull request.
As I am running low on time, doing this in my little free time, and a reply may seem to take months, I'll be working with a temporary solution using our own image version. If you somehow are able to answer in the next 24h, I will be able to provide the files in a timely manner. Otherwise, I may take my time.

Thanks for your hard work guys!

[lastsamurai26]

What I can say at the moment is that the image was created manually at the time and was not automated, so the current version is still 4.2.3.

Unfortunately, I can't reach our developer right now, so I can't give you any further information.

I should point out that we do this in our spare time alongside our regular jobs ;-)

[YamiDoesDev]

All fine. Sorry for my harsh words, I did/do my contributions here in my free time as well. The "org" I was referring to is just some sort of voluntary work, so no money there :c

I know about the images and can imagine, how they were built and published. Just the info about "private or public" runner is not clear, as the runner used in this repo is pretty old already. If the dev can answer this at some time, cool! If not, I will just use the public one.

I will create a merge request for an automated image build and push, once I cleared my code up. Probably on some weekend.
Till then, have a good one! :)

[JulianPrieber]

To make this perfectly clear: Latest is not stale.

Docker and the web version follow separate release schedules.

This repository only contains files related to the Docker code base, not the web application.
We aim to include all necessary files in the latest Docker package so it can be set up without an internet connection.

The Docker image is updated each time this repository is updated.
The Latest Docker release contains whichever version was current at the time of the build. To update the LinkStack version inside the container, the built-in updater is intended to be used.

---

Everything needed to build the latest Docker image from source is included in this repository. Doing so will always give you the most up-to-date packages and the latest LinkStack release.

---

The next LinkStack update will require a new PHP version, and this repository will be updated accordingly.

A new, more performant Docker setup is also in the works, so I hope it can be forgiven that this repo has seen a bit less love lately.

---

To be completely transparent: I did attempt integrating the Docker release into our automated release schedule, but for some reason my script refuses to authenticate with Docker Hub when running in GitHub Actions.

I tried everything (password and API authentication), but it never worked on the GitHub VMs. Locally, it works fine and honestly, I’m too tired to troubleshoot this further.

If anyone wants to take a look, that would be a huge help.

Here is the script:
https://github.com/JulianPrieber/php82test/blob/main/.github/workflows/release.yml#L135-L175

Latest attempt (auth step):
https://github.com/JulianPrieber/php82test/blob/main/.github/workflows/release.yml#L146

[JulianPrieber]

Many thanks @lastsamurai26

[rlue]

It sounds like you're saying that for this project, the Docker image tags are not intended to correspond to application image versions. Is that correct? (I notice that linkstack's image tags on Docker Hub correspond mostly to platforms, like amd64 or arm32v7, though also others that don't fit this pattern, like unraid and V4.)

If so, I have to insist that this is not a best practice. In every Docker application I've ever deployed (and I have deployed many, from many vendors), image tags correspond to a specific application version and upgrades are performed by pulling the latest image, which latest is repeatedly updated to point to.

Of course, I understand that linkstack is free software and I'm not entitled to anything from your organization. But to say that latest is just what version we were on when the image was built is circular and self-evident. If you mean to say that latest is intended to be a few versions older, that's fine, but in-container upgrades break the design of container images, where you should be able to destroy and re-create a container without affecting the application itself, because the application filesystem is stateless, and volume/FS mounts are used only for application data.