All,
Attempting to use Heroku's new-ish Continuous Integration service but it doesn't appear to want to play well with its own framework.
I've setup my Heroku Pipeline as outlined in the CI article: https://devcenter.heroku.com/articles/heroku-ci#configuration-using-app-json.
My deployments to review apps work correctly.
But my CI tests error with the following
app.json
"buildpacks": [
{ "url": "heroku/jvm" },
{ "url": "heroku/nodejs" }
],
Results in
$ heroku ci:debug --pipeline mypipelinename
Preparing source... done
Creating test run... done
Running setup and attaching to test dyno...
~ $ ci setup && eval $(ci env)
-----> Fetching heroku/jvm buildpack...
error downloading buildpack
I'm using the JVM buildpack so that I may install liquibase which manages version control for my Postgresql DB, but I'm actually deploying a NodeJs app.
Why would my "Review App"s deploy without problems but die during "Test Setup"?
I managed to get past this by using the github url for the node buildpack
"buildpacks": [
{
"url": "https://github.com/heroku/heroku-buildpack-nodejs"
}
],
I imagine it will work the same for jvm
Related
I would like to provide a button from github to directly deploy an app.
Its a go application which serves some website.
Now for persistent data it requires an addon "Heroku Postgres".
I tried defining a heroku.yml with:
setup:
addons:
- plan: heroku-postgresql
I tried app.json with:
{
"addons": ["heroku-postgresql:hobby-dev"]
}
But it does nothing at all, it never adds the addon. I know I can add it manually through the website or CLI, but I want a fully automatic way - if that is possible.
It should look something like this
"addons": [
{
"plan": "heroku-postgresql",
"options": {
"version": "12"
}
}
]
Example app.json from heroku
I am developing a quick ASP.Net Core 3.1 app, and trying to push it to a Free Linux-hosted WebApp in Azure.
The app builds, runs locally, and deploys to a docker environment in Windows Azure. All the files are deployed as expected.
The challenge is this:
Upon starting the app using the command
dotnet <mywebproject>.dll
The log tells me this:
The framework 'Microsoft.WindowsDesktop.App', version '3.1.0' was not found.
First thing to check was to see if there was a missing runtime
root#4182491:~/site/wwwroot# dotnet --list-runtimes
Microsoft.AspNetCore.App 3.1.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
After some fondling, I see that there is a file named .runtimeconfig.json:
{
"runtimeOptions": {
"tfm": "netcoreapp3.1",
"frameworks": [
{
"name": "Microsoft.WindowsDesktop.App",
"version": "3.1.0"
},
{
"name": "Microsoft.AspNetCore.App",
"version": "3.1.0"
}
],
"configProperties": {
"System.GC.Server": true
}
}
}
So the runtime I need is there, but dotnet does not want to select it!
From the error, I am assuming that dotnet is attempting to start the website using the first framework that it can see, however how do I get rid of it during build? I've looked up how these files get generated during build, and can see no options to prevent a framework from being put into the runtimeOptions file.
Since I am building the app using Azure DevOps, I can't simply edit the file manually and upload it to the hosted linux container that it runs in.
So I need help with either:
How to build the project and EXCLUDE "Microsoft.WindowsDesktop.App" from the list of frameworks being generated
How to START the application in the linux container with a specific target framework NAME (I can only choose version from the settings I see in dotnet exec using SSL to the container.
This is more or less driving me nuts!
I am going to answer this one myself, since I found the solution after way too much coffee:
Turns out that the options you see here:
{
"runtimeOptions": {
"tfm": "netcoreapp3.1",
"frameworks": [
{
"name": "Microsoft.WindowsDesktop.App",
"version": "3.1.0"
},
{
"name": "Microsoft.AspNetCore.App",
"version": "3.1.0"
}
],
"configProperties": {
"System.GC.Server": true
}
}
}
Aren't options at all, but requirements. I found a dependency on a package designed for WPF that of course requires the Microsoft.WindowsDesktop.App runtime to be installed. Since I'm developing on a windows computer, the code had all the necessary runtimes to run in debug, but not on linux.
I'll close this for now, but since the naming led to confusion, I will leave the question up in case someone else runs into the same confusion that I did.
I am setting up a Heroku pipeline and I want to add the "add-on" attribute however I did not see them be applied to my environment.
The format of the add ons block is:
"addons": [
"sendgrid",
{
"plan": "deployhooks:http",
"as": "SLACK-ENG-STATUS",
"options": {
"url": "THIS IS A RANDOM URL"
}
}
],
Is that the correct syntax to create the add-on? I do not see the configuration in the staging app when I directly deploy to it.
Do you expect your addon to be created on deploy? Because that is not how the app.json works. The app.json only created your addons for:
Review apps (https://devcenter.heroku.com/articles/github-integration-review-apps#app-json)
When you use the platform API to create your app (https://devcenter.heroku.com/articles/setting-up-apps-using-the-heroku-platform-api), including through the Heroku Button
If you already have an existing app, entries in the app.json will not modify it on deploy.
I would like to deploy my app onto a Cloudfoundry node. Using composer for dependency management.
Now there is one repository with private packages, which is secured by basic auth (Example https://composer.example.com).
"repositories": [{
"type": "composer",
"url": "https://composer.example.com"
}]
By default, i'm using a auth.json with the needed credentials, and composer would use it.
{
"http-basic": {
"composer.example.com": {
"username": "max",
"password": "mustermann"
}
}
}
But, pushing my app to a Cloudfoundry node, composer gets executed and will fail when it comes to include the private packages.
The 'https://composer.example.com/the/package-1.7.3.zip' URL required authentication. You must be using the interactive console to authenticate
Updating my dependencies locally works like a charm, deploying my app with capistrano for exmple, works as well. But cloudfoundry in some way does not recognize the auth.json.
Any hint or help would be much appreciated.
I have the following release phase in my Procfile:
release: bundle exec rake db:migrate
It works great when I merge PR's into my staging and production apps, but it fails when running on a new review app. The Heroku docs say that the release phase is run after a successful build, so I don't know why it can't find bundle.
This is my output
heroku releases:output 9 --app my-app-pr-253
/bin/sh: 1: bundle: not found
For Heroku's review apps, you must specify all buildpacks and ENV vars you need in the app.json file. You can either manually create one, or have Heroku generate one for you.
https://devcenter.heroku.com/articles/github-integration-review-apps#app-json
Confirm that in your app.json you have specified
1) The required buildpacks https://devcenter.heroku.com/changelog-items/670. Since you are using bundle I'm guessing heroku/ruby will be one. Below is an example.
"buildpacks": [
{
"url": "https://github.com/heroku/heroku-buildpack-ruby.git"
},
2) Also make sure you specify any config variables that you want to inherit from the app off which your review app is being built. https://devcenter.heroku.com/articles/app-json-schema#env Missing one of these could also be causing a build to fail.
If neither of these work, try checking the logs for your heroku app. Watch the ones in the Heroku GUI during the build. Also try to tail the logs in the CLI.
heroku logs -t -a <review_app_name>
I figured out my problem. It was a silly typo:
"buildpacks": [
{
"url": "heroku/ruby",
"url": "https://github.com/guillaume-tgl/heroku-buildpack-ghostscript.git"
}
]
should have been:
"buildpacks": [
{ "url": "heroku/ruby"},
{ "url": "https://github.com/guillaume-tgl/heroku-buildpack-ghostscript.git" }
]