Container Updates and Releases about gns3-registry HOT 10 CLOSED

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.

from gns3-registry.

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.

from gns3-registry.

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

from gns3-registry.

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.

from gns3-registry.

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!

from gns3-registry.

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?

from gns3-registry.

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.

from gns3-registry.

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?

from gns3-registry.

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.

from gns3-registry.

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

from gns3-registry.