Container Updates and Releases

[alexhorner]

Hi there,

So with my PR #761 being accepted, I have noticed that the container has not been pushed to GNS3 on Docker Hub. I wanted to enquire as to the frequency of container builds. Both, for this initial build, and for updates.

If I were to push an update to the image upon which the GNS3 image is based upon, how long would it take for the GNS3 image to rebuild?

Thanks!

[grossmj]

I have to manually push it on Docker Hub, I will do it in the next few days. At the moment our Docker Hub account doesn't support automated builds but we have some alternatives we need to work on to support that.

[alexhorner]

I have to manually push it on Docker Hub, I will do it in the next few days. At the moment our Docker Hub account doesn't support automated builds but we have some alternatives we need to work on to support that.

Oh, interesting.

Potentially you could use GitHub actions to build and push? This should appear to Docker Hub no different to a person pushing manually from the command line.

[grossmj]

Potentially you could use GitHub actions to build and push? This should appear to Docker Hub no different to a person pushing manually from the command line.

Yes we intend to use GitHub actions to build and push (only for the images that need to be updated). We actually have one issue opened for this: #468

[grossmj]

I have pushed the image: https://hub.docker.com/r/gns3/mikrotik-winbox

We will focus on #468 for the auto rebuild part. Thanks again and please don't hesitate to post if you see a problem.

[alexhorner]

Potentially you could use GitHub actions to build and push? This should appear to Docker Hub no different to a person pushing manually from the command line.

Yes we intend to use GitHub actions to build and push (only for the images that need to be updated). We actually have one issue opened for this: #468

Hey there,

I see everything has been merged in to support this, but I have one major concern. You specified "only for images that need to be updated" and I am assuming this means an image will need to be updated in this repository for the process to even trigger let alone work?

This is concerning for my (and other) images which point to a third party container, as no changes will need to be made in this repo, yet upstream images will update and a new version must be pulled.

Thanks!

[grossmj]

I see everything has been merged in to support this, but I have one major concern. You specified "only for images that need to be updated" and I am assuming this means an image will need to be updated in this repository for the process to even trigger let alone work?

This is correct or we can also manually trigger the process.

This is concerning for my (and other) images which point to a third party container, as no changes will need to be made in this repo, yet upstream images will update and a new version must be pulled.

I am not sure how we could handle this. @b-ehlers do you have an idea or comment?

[ghost]

The build tool checks for every docker image, defined in docker/docker_images, the following:

• image name included in the command line?
• files in the docker image directory within this repository have changed, for example by a git push
• image is missing in target docker repository
• base image has changed

All docker images, that meet any of these conditions, are rebuild.

The build tool is run on every git push, weekly and by a manual trigger.

So when you change your image alexhorner/winbox-dockerised the next run of the build tool sees that the base image for docker/mikrotik-winbox has changed and triggers a rebuild. In the worst case you have to wait for the next weekly run, so it can take up to 7 days.

[alexhorner]

The build tool checks for every docker image, defined in docker/docker_images, the following:

* image name included in the command line?

* files in the docker image directory within this repository have changed, for example by a git push

* image is missing in target docker repository

* base image has changed

All docker images, that meet any of these conditions, are rebuild.

The build tool is run on every git push, weekly and by a manual trigger.

So when you change your image alexhorner/winbox-dockerised the next run of the build tool sees that the base image for docker/mikrotik-winbox has changed and triggers a rebuild. In the worst case you have to wait for the next weekly run, so it can take up to 7 days.

7 days seems perfectly reasonable for most updates, and if there is a critical security vulnerability, I am sure an issue could be opened asking for a manual trigger?

[ghost]

Sure, you can create an issue asking for a manual trigger to get an earlier update.

But an updated image doesn't mean, that the update gets to the user. Currently GNS3 loads an image the first time you put a device, based on that image, into a project. Afterwards GNS3 never updates that image. There is no way in the GNS3 GUI to ask for a docker image update. The user has to manually do a docker pull <image>. I assume, that most users don't do that, so they stay with their outdated image. For details see issue #145.

[alexhorner]

Sure, you can create an issue asking for a manual trigger to get an earlier update.

But an updated image doesn't mean, that the update gets to the user. Currently GNS3 loads an image the first time you put a device, based on that image, into a project. Afterwards GNS3 never updates that image. There is no way in the GNS3 GUI to ask for a docker image update. The user has to manually do a docker pull <image>. I assume, that most users don't do that, so they stay with their outdated image. For details see issue #145.

Yea, this is something I noticed too. I personally do pulls, but I do not expect the average user to even know a pull is possible, let alone keep on top of it. It would be good if there was a way for GNS3 to check for updates against the repository and alert the user to an available update and allow them to update either all, or a list. But yea, as you said, #145