Deploying Flask app with npm dependencies

Troubleshooting and help
,
1

My flask app is a simple personal website that require the Bulma the css framework to be installed. I am using SCSS so I need the framework to be installed as dependency rather than as CDN link embedded into the HTML.

Currently, I am using Buildpack and deploying from GitHub repository, the app failed to start as it can not find the Bulma files.

So how can I do this from the control panel or I will have to do it in GitHub Actions?

Thanks.

2

Hi!

You would need support for multi-language buildback. We do not provide this yet. You can upvote for this feature here: Multi-language build | Voters | Koyeb

3

Thank you very much the heads up, I have upvoted the feature.

So can I assume the current workaround would be to deploy my app as a docker container?

4

You could also use a Dockerfile to build your service instead of Buildpack.

5

I now going via the Dockerfile route, and after following 2 of your examples. I kinda arrived at a deployable state.

However, when I use GitHub actions (following one of your example), to deploy the app, I keep getting the following error message:

Error while creating the service: the Keyob API returned an error 400: Validation error
Additional details
Field definition.instance_types.0.scopes.fra: Instance type “nano” not available with current plan “hobby23”

Is there anyway to change the instance type to “free” inside the GitHub Action?

6

Hi @Paul_Lee,

You can use service-instance-type. All available parameteres are described here GitHub - koyeb/action-git-deploy

7

Thanks for the heads up and the documentation, that was really helpful and I now can deploy using GitHub Action.

Although the deployment was successful, there are 2 outstanding issues:

  1. Large variance on Instance performance, since I need to do apt-get installs, the deployment process is long. However, sometimes the process is able to complete before the Health Checks shuts it down, most of the time it took longer and the Health Checks failed a potentially long but good deployment.

  2. Health Check Grace Period, in the action-git-deploy documentation, if I didn’t specify the “healthy-timeout”, the default value is 900(s) however, the “Grace Period” setting under the “Health Check” section, won’t accept anything more than 300(s). So if I use github action to deploy which value of the Grace Period counts?

It is the similar story about the field “service-checks”, it defaults to no checks, but the Control Panel doesn’t allow deleting all checks, there must be at lease one specified.

8

On Koyeb, healthchecks can be configured with four different parameters:

  • Grace period: the amount of time to wait before starting the healthcheck, in seconds. This is useful to configure a delay when the application takes some time to start.
  • Interval: how often to run the healthcheck, in seconds.
  • Restart limit: the number of times the healthcheck can fail before the application is restarted.
  • Timeout: the amount of time to wait for the healthcheck to complete, in seconds. If the healthcheck takes longer than this time, it is considered as failed. If the healthcheck returns a connection refused for example, this value is not taken into account: the healthcheck is considered as failed immediately.

The project action-git-deploy can be used to configure your CI to deploy your application to Koyeb. Note that alternatively, you can create a service on Koyeb with the GitHub source, and set the flag “Autodeploy” which is set by default and which will automatically rebuild and redeploy your application when the source branch is updated.

When you are using action-git-deploy, the action will:

  • create or update a service on Koyeb with the configuration you provide
  • wait until the build is finished, and meanwhile, display the logs of the build
  • wait until the deployment is healthy, and meanwhile, display the logs of the deployment

To avoid waiting for too long, the parameters build-timeout and healthy-timeout can be configured. These parameters are set to 15 minutes by default, and are not related to the healthchecks. If the build or the deployment takes longer than the timeout, the action will simply fail.

action-git-deploy doesn’t currently allow to configure the healthchecks. As a work around, you can edit your service manually from the control panel, and set a higher grace period.

I intend to add the possibility to configure the healthchecks in the action-git-deploy in the future, but I don’t have a timeline for this yet. If you need this feature, feel free to create an issue on the repository!