[Feature Request] Ability to repull images and/or force redeployment of stacks

[OliverKellyATech]

Problem statement

Hi Team,

Here is the problem we are facing. We use a "gitops" workflow to build and deploy images in our Gitlab CI/CD pipelines, and currently use Portainer for stack management and deployment via webhook.

The problem is, when using the same workflow in Dockhand, whilst our images are updated and built as part of the CI/CD pipeline, our images almost always use a static tag (eg: :latest or :prod or similar). So the intention at the end of the pipeline would be that the updated images are pulled and redployed.

The issue is that the docker compose file which defines the stack does not (or rarely) changes, so the webhook redeployment in Dockhand does not detect any changes to the stack definition.

In our Portainer based workflow, this is overcome using the Gitops "Re-pull image" option on the webhook invocation.

Proposed solution

We would like to see the ability to do the following when managing stacks that are git controlled:

• Repull images: If enabled, then when redeploy is triggered via the webhook or polling, if there's a newer image with the tag that you've specified (e.g. changeable development builds), it's pulled and redeployed. If you haven't specified a tag, or have specified 'latest' as the tag, then the image with the tag 'latest' is pulled and redeployed.

Essentially, this will allow CI/CD systems and other automation tools to pull updated images and restart the stack even when the docker compose file is unchanged (eg: services you have built/rebuilt, but you use the :latest tag in the compose stack definition).

Additionally, a second option my also be supported (these are based on the "gitops" workflow options support by Portainer:

• Force redeployment: If enabled, then when redeploy is triggered via the webhook or polling, the stack will be always redeployed, even if the system detects no difference between the git repo and what was stored locally on last git pull.

In addition to the options above triggering on webhook or on scheduled sync, the options should also trigger on manually entering the "Git deploy" option of the Stack actions.

Alternatives considered

No response

Additional context

An example of the "Gitops" features for a Stack managed via Portainer, including the requested Re-pull Image option:

[jotka]

scheduled for 1.0.23

[kaat3g]

A very requested feature for stack management: #152

[jotka]

ok @OliverKellyATech @Robertas1975 this is how it will look like

documented here https://dockhand.pro/manual/#deploy-options

When all integration tests pass (~2hr) i will give you a build to test.

[jotka]

here we go fnsys/dockhand:ffb5ed85.
Note, if using Hawser on nodes, you'll need to upgrade Hawser to v0.2.38. The change in Hawser is backward compatible, so when you are done with Dockhand tests, you ma leave Hawser upgraded.