I'm trying to deploy a runnable Spring Boot jar via Heroku CLI.
On 2018-11-06 it was sufficient to define the java.runtime.version=11 Config Var in the application settings.
Since 2018-11-07 Heroku ignores it and uses the default 1.8 Java. I have also pushed the system.properties file with content java.runtime.version=11, but it gets ignored either.
Does anybody have a workaround for this?
Make sure you have commited changes to the master branch of your local git repository before pushing to Heroku.
Related
I need to set my spring boot cloud config server to read properties from git repository. But if git is down then it should read from local repository property files. Can anyone help on this please?
You can use spring.cloud.config.server.git.basedir = your/path/folder
Using this, if your app has been able to connect once to git, it will create
the specified directory and clone the files from git as fallback.
When your git repository will be unreachable the app config server will use those files.
Also there is this spring.cloud.config.server.git.clone-on-start = true/false.
If this is true when the application restarts the folder contents will be deleted and cloned again. You might want to set this to false if you want the files to be kept between restarts. Also if you want to have the fallback available before the first start, you just have to clone the git project locally, and put that path as the basedir.
Currently my Heroku CI tests are triggered on all git push to master branch at Github.
Is it possible to avoid triggering CI tests if specific files are being pushed, such as README.md?
Pretty sure heroku processes the .slugignore file for CI as there's an open issue now for ignoring it: https://github.com/heroku/heroku-ci/issues/39
The slugignore docs say
The .slugignore file causes files to be removed after you push code to Heroku and before the buildpack runs.
I don't use heroku ci so I wasn't able to test for sure. YMMV
I have a java webapp on heroku. It runs perfectly on the cloud. But when run locally it appears to use a stale resource. My jar is called nymmbl1-1.0.jar. I have 100% verified the resource is correct in target\nymmbl1-1.0.jar and ~.m2\repository\com\nymmbl\nymmbl1\1.0\nymmbl1-1.0.jar. When run locally the resource is old. It's as though heroku local is using some cached version.
Has anyone ever seen anything like this?
The out-of-date resource is a local read-only SQlite database. When running "heroku local" the database is accessed but the content returned is different than the actual database content in the current jar. The content returned is from an older version of the SQLite DB that is not in the current JAR.
As I said, this problem is not observed when run on the cloud.
My guess is that "heroku local" is doing something I don't expect. Can you suggest what may be the problem or how to debug this?
This problem disappeared upon updating some maven artifacts. For the record here's what I changed:
org.springframework.boot spring-boot-starter-parent, changed from
1.5.2.RELEASE to 1.5.7.RELEASE
webjars-bootstrap.version, from 3.3.6 to 3.3.7-1
webjars-jquery-ui.version 1.1.14 => 1.12.1
webjars-jquery.version 2.2.4 => 3.2.1
thymeleaf.version 3.2.5.RELEASE => 3.0.7.RELEASE
travis has a config to set the buildpack source for heroku deployment using the Anvil deploy strategy, but it doesn't specify how to set that config value using the git deploy strategy.
how do you set buildpack config value as a heroku config variable before deployment if you're using the git deployment strategy in travis?
thanks.
For git deploys, Heroku relies on the BUILDPACK_URL environment variable to be configured for your repository.
Anvil doesn't utilize these settings, hence it needs to be manually specified in the deployment settings.
I know that a git push origin master will let Openshift redeploy the application to its new version.
But my situation is that my Tomcat application depends on another sub-module maven project, and they are both snapshot.
Once its sub-module project changes (the Tomcat application remains the same), the git push origin master doesn't work at all (Everything up-to-date) and of course Openshift will not redeploy my application, which means that it doesn't renew the newest sub-module snapshot artifact for me.
So, how to solve this problem? I have tried rhc restart and rhc reload, but they doesn't work. Is there some command like rhc redeploy?
You can run
rhc app deploy HEAD -a <appname>
if you're using the command line tools
You can start the deploy steps by ssh'ing to your openshift application. Check your ssh line from https://openshift.redhat.com/app/console/applications/ -> Click your application and then "Want to log in to your application?". Check https://www.openshift.com/developers/remote-access for detailed help (thanks RustyTheBoyRobot).
Once in, run:
gear deploy
Are you sure that you've pulled and committed the most recent changes to the submodule? What's probably happening is the reference to the desired submodule commit isn't updated, so even though the submodule has changed, you project doesn't really know about it. I believe git submodule status should show you the commit your main project currently knows about.
To update this reference, follow these directions.
[main]$ cd ./subm
[subm]$ git pull origin/master # or fetch then merge
[subm]$ cd ..
[main]$ git commit ./subm -m "Updated submodule reference"
If you actually committed changes in the last step, then OpenShift should update it appropriately (since this time, there were changes to the git repo).