Add webhook or alert

[millievn]

Please read CapRover goals and scope before posting a new feature request.

Is your feature request related to a problem? Please describe.

I deploy nextjs app by docker and sometimes it fails. It's hard to stare to deply process and see when it success and why it fail. And it's more hard to work with several developers with different authority.

Describe the solution you'd like

Maybe we can provide some webhook or anyother to monitor different process like build/deploy and send docker errors.

[githubsaturn]

I agree - something like this would be useful. But we shouldn't limit it to report only build failures. Instead, we need an event publisher that publishes all events such as login, app creation, app updates, deploys etc... Users can choose to filter and do whatever they want with the events.

[sean-nicholas]

This sounds pretty cool. Here are some ideas that we might want to brainstorm about.

Retry on fail

Webhooks should be retired if they fail the first time. Maybe 5 - 10 retries with increasing time between them. Cool would be a message if it still failed but then we would need to add mail or something.

I think this part of the feature does not need to be in the first version because it is realtively comprehensive. For example caprover would need to track which webhook didn't worked and when to retry it again.

Conditions

Most likely one want to define some conditions when the webhook should be called. Like "inform me if app XYZ was deployed".

I think this can get pretty messy pretty fast if we create an UI for all those cases. We would have to add thinks like and, or, starts with, equals, like, etc. And each event has different parameters that would need to be selectable.

A better solution might be the following:

Javascript Hook Function

Maybe the UI should only have the following two inputs:

• select for choosing the event type
• textbox that accepts JS code that is run when the event is fired.

The JS code would be similar to the preDeployHook. You get the event information & maybe the caprover / app object. Then you could do all the conditional filtering on your own.

Even better you would be free to do whatever you want in that function. So no limitation on sending a http request. Maybe you want to send multiple requests or an email or just do something on the server itself.

So the function would just return a promise that indicates if it was successful. If not, the function will be rerun again (see retry on fail above).

Maybe it could look like this:

const hook = ({ event,  captainAppObj }) => {
    return Promise.resolve()
        .then(() => {
            if (event.appName !== 'client') return
            return http.get('[URL]')
        });
};

[iameru]

I'll second this as useful if my pull from github for example fails, caprover tries to build it again. and again. endlessly. never succeeding.

and now I made a change to my codebase, depending on "user interaction" after deployment to migrate databases. Without a POST-hook this is extremely hard to setup.

[davidzwa]

I also would like to see this in order to make my clients aware of the actively deployed version of CapRover.

A second reason/purpose is to be able to do healthchecks not inside Docker (so customizing the endpoint) and possibly auto-reverting to a stable version based on certain criteria. I've had healthchecks fail on me before, without notice from CapRover. Similar to @iameru CapRover would keep on trying and trying. A revert + Slack notification (webhook) would have fixed that.

[alexander-potemkin]

@davidzwa , not to challenge you, but out of curiosity and for my self-education, as I'm now changing my approach - why don't you build your Docker images outside of CapRover?

I don't, because it's extra efforts - to setup selfhosted GitLab and extra money - to run extra server - for GitLab or for GitHub actions.

Wondering what are the other show-stoppers and issues around.

[davidzwa]

@davidzwa , not to challenge you, but out of curiosity and for my self-education, as I'm now changing my approach

No worries!

Why don't you build your Docker images outside of CapRover?

I do on one project and I would do so if I had more Dockerhub private images left. The next challenge is letting caprover deploy that specifically built image. That is a matter of installing the CapRover CLI on your CI/CD and pushing the image label/tag.

I don't, because it's extra efforts - to setup selfhosted GitLab and extra money - to run extra server - for GitLab or for GitHub actions.

A docker registry is free to self-host! I was considering it.

Wondering what are the other show-stoppers and issues around.

1. CapRover image builds becomes significantly slower on cluster mode. A CR like Dockerhub fixes that.

2. An actual question that we need to ask is: how can CapRover aid in a deployment pipeline like the following:

• Dev for PR commits or approval => Staging for each merge (develop branch)

And for releases:

• Staging for prerelease => Production for release

Each of these steps could test the image and perform healthchecks resulting in persisting the image or rolling back to a previous image label/tag. But what if we want to run smoke tests or perf tests? Are we supposed to bake that into our application container, deploy it on our CI/CD or trigger a separate app for that (f.e. with grafana k6) with CI/CD checks/scripts to get the results?

It all ends in or depends on the post-deploy script or webhook. Alternatively we can create a daemon/manager app to push back the healthcheck results for our Github Action/CircleCI/Azure DevOps Pipeline/AppVeyor/Jenkins to do a manual rollback.

[alexander-potemkin]

thank you, @davidzwa, it's quite a detailed answer and things to consider.

Did you consider self-hosted GitLab for that purpose? They seems to advanced in CI/CD, what about some combination of both?

[genox]

I think this would be very useful, too.

Up until now I was building all containers on a local runner that is connected to my gitlab account, telling caprover to fetch the new image and launch the container, using a gitlab registry for image storage.

However, in an effort to cut down vendor lock-in and since I don't need an elaborate setup for most projects (test stages, etc..) and it is simply enough to build -> deploy on two branches (e.g. main and dev), I thought this might pose a good opportunity to simplify my setup and rely on caprover to build the docker image.

After I got that working and became uniquely excited about the new level of simplicity, I was looking for a way to be notified of any build errors and ended up here. :)

A post-build or post-deploy hook that allows to parse some object for errors to fire off a web hook somewhere else would be plenty enough for me, to be honest.

[SaadBazaz]

Better yet. Just like how Vercel shares a "deployment status" as soon as you push.

When pushed -> Build in progress:

When build completes successfully:

Something like the above for CapRover would be super cool.

[githubsaturn]

Email alerts Available as of 1.11+ as part of the pro plan. Webhook will come later.