[Bug]: AL-Go docker pruning too aggressive(?)

[SteveKrisjanovsD365]

AL-Go version

6.3

Describe the issue

We have a private Azure VM we've been using for the past year to unit test development tickets (for both saas and onprem apps). The docker instances on that VM are created via bccontainerhelper with the usetraefik option.

last week we installed self-hosted github runners on the same VM (because our standard github-hosted runner build pipelines were failing for apps with large third party dependencies)

My team alereted me this morning that ALL BC containers on that VM are GONE (both saas and onprem containers).

Are the AL-GO self-hosted runners performing any container cleanup/housekeeping? If so, it appears the current housekeeping that is implemented in algo/bccontainerhelper is far too agresssive (why its pruning containers NOT created by AL-Go itself is beyond me).

Please consider adding in settings to whitelist by wildcard which containers AL-GO should and shouldnt touch.

Please advise.

The self-hosted runner documention BTW doesn't mention any risks of running a self-hosted runner on a server where bccontainerhelper is actiively used locally.

Expected behavior

al-go/bccontainerhelper shouldn't touch/purge BC containers not spun up by AL-Go

Steps to reproduce

create a docker container (saas or onprem) on a machine via bccontainerhelper. next, install a self-hosted runner on the same machine. I don't know the details beyond that, but eventually the self-hosted runner will kill off the BC Container previously created (by docker container creation date?)

Additional context (logs, screenshots, etc.)

No response

[freddydk]

The self-hosted runner documention BTW doesn't mention any risks of running a self-hosted container on a server where bccontainerhelper is actiively used locally.

Sorry, I never considered that people would use the same server for builds etc.

Currently, the only thing you can do is to set "cacheKeepDays" to f.ex. 9999 (meaning that BC will not remove things from the cache if it has been used during the last 365 days.

We will consider adding some more control over this (+ adding this to the docs)

[SteveKrisjanovsD365]

@freddydk thanks for the update!

I honestly assumed that algo would simply prune unreferenced image artifacts, not the containers themselves (let alone touch BC containers that are type=onprem).

Whatever flushing went on , algo blew away all of them.

In the meantime I'm going to remove the self-hosted runners I created. They're far too dangerous to run on a multi-purpose server.

[freddydk]

TBH - I didn't think it would ever remove running containers - it shouldn't.
It should remove exited containers - but it is probably a good idea to only remove AL-Go containers.

[SteveKrisjanovsD365]

@freddydk

The non-algo containers it removed were not running at the time.

To conserve on docker host resources I wrote a script to STOP all containers on the VM on every morning at midnight.

[freddydk]

Understood - that would be the reason why.

[SteveKrisjanovsD365]

@freddydk FYI we've since removed and uninstalled the self-hosted runners, and in it's place we provisioned an org-level "large" github-hosted runner and updated our algo settings accordingly to use it for the repo(s) of interest.

its working like a charm.