Issue: Files not updating after deployment with DockPloy Git provider 😵‍💫

[SamuelChojnacki]

Hello everyone,

I’ve installed DockPloy on my server, where I host several services (frontend, database, analytics), and I’m very happy with it so far. However, I’m facing a persistent issue when deploying a Strapi backend application via a Dockerfile. Despite everything seemingly working as expected, the application does not reflect the latest changes from my GitHub repository.

---

My Deployment Process
1. My Dockerfile is stored in my GitHub repository alongside my Strapi code.
2. On every push to the main branch, DockPloy is set up to:
• Build a new Docker image.
• Deploy the new container automatically using the updated image.
3. DockPloy is connected to my GitHub repository via a webhook URL as per the documentation. The webhook request passes successfully (HTTP 200), and the deployment process is triggered.

---

The Problem
Despite DockPloy indicating that the deployment is successful:
• The changes made in my GitHub repository are not reflected in the deployed container.
• When I access the container’s terminal, I only see old files, without the latest updates from my pushes.
• The container restarts as part of the deployment process, but it keeps running on an outdated image.

Further Observations:
• Using docker images, I can see that new images are being built correctly after every push.
• However, when running docker ps, I notice that the container is still running on an older image with the tag (likely cached).
• It seems DockPloy is not using the latest built image during deployment but instead reusing an older one.

---

My Setup

Folder Architecture:

This is how my project is structured:

i don't use the docker compose actually

---

Deployment Dashboard:
Here is a screenshot of my DockPloy deployment dashboard for the application:

---

I have one volume mounted

--

My Dockerfile
This is the Dockerfile I’m using to build my Strapi application:

FROM node:20.11.1-alpine3.19 AS builder

WORKDIR /opt/app

COPY package.json yarn.lock ./

RUN yarn global add node-gyp && yarn config set network-timeout 600000 -g && yarn install

COPY . .

RUN yarn build 

FROM node:18.16.0-alpine

RUN apk update && apk add --no-cache vips-dev && \
    rm -rf /var/cache/apk/*

WORKDIR /opt/app

COPY --from=builder /opt/app .
COPY --from=builder /opt/app/node_modules ./node_modules

EXPOSE 1337

CMD ["yarn", "start"]

---

What I’ve Verified So Far
1. Webhook Configuration: The webhook URL is correctly set in my GitHub repository settings. The webhook successfully triggers (HTTP 200) and initiates the deployment process.
2. Container Restart: The container does restart after each deployment.
3. Image Creation: New Docker images are being built correctly after each push, as confirmed by the docker images command.

---

Observations:
• The docker images output shows several images, which I suspect are older versions of my Docker images.
• The docker ps output shows that the running container is still tied to one of these older images.
• I’ve made two pushes so far, and neither of them seems to have updated the running container.

---

Additional Context:
I’ve attached a screenshot for reference, showing:
• The output of docker images with new images created after each push.
• The output of docker ps, which shows that the running container (mitain-back-end) is using an old image.

---

Hypotheses
1. DockPloy might not be correctly using the latest built image during deployment and is instead reusing an older cached version.
2. There might be an issue in the Docker image tagging process or the container configuration, which prevents DockPloy from picking up the updated image.

---

Questions
1. How can I ensure that DockPloy always uses the latest image built from my GitHub repository during deployment?
2. Is there a specific configuration required in DockPloy to force it to use the most recent image and avoid reusing cached images?
3. Could the tag on older images in docker ps indicate a misconfiguration in the image build or deployment process? If so, how can I fix this?

Thank you in advance for your help! 😊
4. My mounted volume could be interfering with the updates, although this seems unlikely since the issue persists even for files outside the mounted volume.