Project cannot deploy from the dash (deploying status never resolves) and Heroku seems to be not accessible (see screenshot). After the latest successful deployment everything was working fine. However, the issue popped up without any other further deployment.
Project ID is 15611
cc @amador.jesus
Hi @jorge.m: you can cancel and redeploy; you should be back online now, but let us know if you see further issues.
@anand The app seems to be up and running. However, not sure if is related, but the backend cannot be deployed (returning an error) since then
Hi @dmitrii.k, now the Django app is deployed successfully. However, OptaPlanner (hosted on the syper dyno) seem to be not responding
Maybe with logs we can know what is happening, I don’t know if you reset all heroku environment but optaplanner needs some specifics env variables.
OptaPlanner is running. If you set the env vars using CB Dashboard, those would’ve been re-applied to the dyno on recovery.
To be honest we was having access to heroku dashboard, and I putted directly those env variables, optaplanner needs database credentials to connect, optaplanner does not accept full url like a django project, springboot needs to have url, username and password to work get a successfully db connection,
DATABASE_HOST,
DATABASE_NAME,
DATABASE_USER,
DATABASE_PASSWORD
spring.datasource.url=jdbc:postgresql://${DATABASE_HOST:localhost}:${DATABASE_PORT:5432}/${DATABASE_NAME:postgres}
spring.datasource.username=${DATABASE_USER:postgres}
spring.datasource.password=${DATABASE_PASSWORD:helpahelpa}
@amador.jesus, thanks for explaining.
You should always use a CB Dashboard to input any environment variables - this makes them the most portable. Your Heroku access was there for advanced functionality not usually provided.
If you are using the same DB that you get from DATABASE_URL env var, I suggest you use a parser in your code, e.g. Parsing Database URL with Java | David's Tech Blog, etc.
This is because the database credentials may be rotated without notice, which will require you to go in and manually set those values again.
Hi @amador.jesus. Your build succeeded, but your release command failed.
What happens during the relaease is controlled by the heroku.yml in your backend folder.
I saw your entrypoint script to set the environment. You’re thinking in the right direction, but have you tested this locally with docker-compose?
When you deploy spring without docker on Heroku, Heroku has a buildpack that sets those values based on the DATABASE_URL in the environment. This is the script they use in the buildpack - heroku-buildpack-jvm-common/jdbc.sh at main · heroku/heroku-buildpack-jvm-common · GitHub.
Hi @dmitrii.k, I already fix something an overriding port variable when I was extracting variables from DATABASE_URL, and I already build it and run it locally, but on heroku we are on the same situation and I don’t know what is happening at all.
@dmitrii.k we would appreciate some guidance. We don’t have any visibility on the logs and @amador.jesus is running out of ideas. Thanks
Ah, then it makes sense - it’s not something, it’s Heroku. You should not override the $PORT or your app will not start/Heroku will not serve it.
@dmitrii.k sorry I did not explain well, the problem was, I was overriding $PORT variable by mistake but I already fixed, then I deployed my changes but we still having problems,
Now locally is already working, but is not working on heroku and without error logs
Thanks for explaining, @amador.jesus.
Your latest builds actually succeeded. As well as your releases. But your release phase doesn’t have any logs and Heroku doesn’t appear to recognise it has finished (partly, because it looks like it’s not finished, but Heroku reports it as finished). This can be a glitch on Heroku, or could be that your release isn’t terminating correctly because you’re running two processes on a single dyno instead of the recommended one.
The app is live, please check if it’s the correct latest version.
If you want to investigate further, please run the command you have in your release phase of the heroku.yml locally in a running app container and see what output/errors you get.
Let me know if I can help you with anything.
@amador.jesus, your latest “normally” looking release is from 21 Dec, commit hash 8227d676bf5a.
The builds began breaking after this one (until you’ve fixed the connection string), and appear to have been fixed after you’ve fixed the $PORT override (see my previous message).
It was working before heroku or crowbotics get down for a while, after that logs doesn’t appear and optaplanner process can’t run (because missing envs)
Did you mean about run heroku.yml file, with some heroku cli?
It would’ve failed as soon as the DB credentials were rotated.
Not exactly.
Launch the Docker Compose as usual, with docker-compose up. Open a second terminal and run: docker-compose exec web python3 manage.py migrate (which is your release command).