I have a small application running there using the heroku-buildpack-perl buildpack. It's just a small Plack application and it had been running fine for about two years.
But then, Heroku informed me that the stack it was running on was getting too old and I needed to upgrade it. "Just run a new deploy and the application will be installed to a new stack!" said they or something like that.
I inniciated a new deploy by creating an empty commit in the git repository, the deployment ran... but the application was crashing. From the logs I realised they updated the Perl version, but the deployment didn't update my XS libraries (I use local::lib, not sure if that's part of the buildpack or I set it up manually when creating the application back then).
In the end, I deleted the application and recreated it on the new stack, which worked OK. I don't keep any data anywhere so it was not a problem. What's the correct way to update the stack, though? There should be an option somewhere that tells Heroku to rebuild the dependencies, right?
Crossposted to PerlMonks.
Setting Heroku stack. In this case to heroku-20 equivalent with Ubuntu 20.04
$ heroku stack:set heroku-20
Since you are using a different stack, the old cache may not be compatible. Clearing cache:
$ heroku plugins:install heroku-builds
$ heroku builds:cache:purge -a appname
Triggering a rebuild:
$ git commit --allow-empty -m "Purge cache"
$ git push heroku master
Note:
You have to make sure that the buildpack you are using is compatible with heroku-20. If it is not it will not work. You will have to wait for the maintainer to update, use a different buildpack or fix the buildpack yourself and use that.
If you follow this step by step it is similar to deploying an entirely fresh app.
Related
I am hosting a Discord bot on Heroku so it stay live 24/7. I have the code local on my computer and update the code by running the below code. My only question is how can I access the code on another computer to work away from home.
git add .
git commit -am "making it better"
git push Heroku master
There isn't a way to "make the folder a GitHub link". Heroku builds your application and its runtime into a slug and this slug is what runs on your dynos. There is no way to update the code you're running without building a new slug.
However, you can deploy directly from GitHub, either manually or automatically when new commits are added to a branch. I strongly recommend having a good test suite in either case, but this is especially important if you want to do automatic deployments.
I've been looking for a solution how to manage my project with git for quite some time now. I want to have one instance as the main repo for connecting the entire project. Each app should be its own git instance.
During my search I found both git submodule and git subtree. For both tools I found an instruction how to insert an existing reppo. However, I am interested in how to proceed from the beginning. I mean here from the command $ django-admin startproject myproject Where do I enter the git init? When I create a new app
$ django-admin startapp new-app and how do I use this as subtree/submodule?
Until now I have always found instructions that refer to a remote repo. Is this always necessary? I am not sure if I want to publish every Django app on Github. But I want a version control system just for me. Is this possible?
I have to say that so far it has been enough to manage my "projects" locally. Now I want to work together with others and I don't want to install the whole Django Project locally but only provide me with single functions or modules.
It would be a great help if you could explain to me how that works.
TL;DR
How to manage (start and expand) a Django Project with git. The apps should be their own git repos.
The purpose of submodules is to allow you to graft an existing repo/library into your git. Rarely do you want to do this. Instead you want to use PIP tools to install your libraries as part of library management.
This is essentially a git question. If you don't have a remote repository, you can still use git. With that said, the reason you want a remote repository is so that you can collaborate with others, and have a stored version of the code separate from your workstation.
There are services that let you have private repos even without a paid account. Bitbucket is the most well known of these services and is comparable to Github in most ways.
What are the best practices for using one mercurial project in another? I've got a django app that I'm working on, but I'm also using mercurial to version control a website that uses that app. I've looked at mercurial subrepositories, but apparently this is considered a "feature of last resort". Is there a good way of doing what I want to do, or do I just have to copy the code from my app into my website repo when I want to update to a new version of my app?
In your specific case I like to let pip handle my django application dependencies: http://guide.python-distribute.org/pip.html#installing-from-a-vcs
We have in our "website" repo a requirements.txt and our deploy does a pip install --upgrade -r requirements.txt That pulls the latest from the repo and installes it into the application's virtual env. This gives nice flexibility and separation while leaving the package management up to pip. With those VCS urls in pip you can point to a specific tag or branch too if you want different sites using different revisions from the same underlying repo.
pip also has a -e /path/to/file mode for pointing to an "editable" clone that's outside the website repo, which would work too, but I've not tried it.
That said, if you think subrepos fit your workflow better by all means use them. They work just fine, but people often get hung up on the workflow constraints ("What do you mean I can't commit my parent repo w/o also committing in the subrepo?!")
I have a Sinatra app, hosted on Heroku. Lately, I've been developing that same app from a different folder. It's not a branch, it's just a parallel app / directory with identical contents but different code. I want to push this new app to Heroku, overwriting the app that's currently there. I don't want to merge the two locally, just continue from the new one while keeping the old. What's the proper command sequence for this? I have doubts about running heroku create, as that will result in a new app. Thanks!
Firstly this is certainly possible. The process is quite simple, firstly we need to add Heroku as a new remote repository to your new app.
heroku git:remote -a project
You would replace the 'project' with your Heroku app name. Secondly you would need to force a push to Heroku.
git push -f heroku master
Note: We are using an '-f' to force the push.
I'm creating a webservice and I want to store the source on github and run the app on heroku. I haven't seen my exact scenario addressed anywhere on the 'net so far, so I'll ask it here:
I want to have the following directory structure:
/project
.git
README <-- project readme file
TODO.otl <-- project outline
... <-- other project-related stuff
/my_rails_app
app
config
...
README <-- rails' readme file
In the above, project corresponds to http://github.com/myuser/project, and my_rails_app is the code that should be pushed to heroku. Do I need a separate branch for the rails app, or is there a simpler way that I'm missing?
I guess my project-related non-rails files could live in my_rails_app, but the rails README already lives there and it seems inconsistent to overwrite that. However, if I leave it, my github page for the rails app will contain the rails readme, which makes no sense.
Also ... I tried just setting it up as described above and running
git push heroku
from the main project folder. Of course, heroku doesn't know I want to deploy the subfolder:
-----> Heroku receiving push
! Heroku push rejected, no Rails or Rack app detected.
Here's a simple solution that may or may not work for you.
Create two projects on GitHub. One project should be just the Rails app (i.e. everything inside the Rails app directory). The other project should be everything outside the Rails app directory.
Add the Rails app project as a git-submodule within the "container" project.
Now you can add Heroku as a remote on the Rails app repository separately and push it to heroku. Heroku will accept the push because it is just a Rails app with the expected directories and files.
A solution for the Heroku situation (not the README file):
If you're using the new Heroku Cedar (I believe it wasn't available when you first asked your question) then your processes (like the rails server process) start up using Foreman. Thus, you can place a Procfile in the root github directory that looks like this:
web: my_rails_app/script/runserver.sh
And then my_rails_app/script/runserver.sh could be a simple
#!/bin/sh
cd my_rails_app
bundle exec rails server -p $PORT
Locally, you should also create a file called .env (note the . at the beginning), which contains
PORT=3000
This file is read by foreman and used to set environment variables so that the port is set when you execute foreman start on your machine (from the root github directory, where the Procfile lies). The Heroku server takes care of the .env file on your dyno. The big advantage is you can set up multiple processes on the dyno that way!
Just overwrite Rails' default README file. There's no reason to keep it around. Put your other project-management-related stuff in the doc directory. While you certainly have valid reasons for wanting to set it up the way you did, you're just creating a headache for yourself by going against convention, and it's probably not worth the benefit.
I would add everything underneath /my_rails_app to the Heroku git repository. Then add GitHub as a remote and add everything underneath /project to the GitHub repository. Then you can push the Rails application to Heroku (from /my_rails_app) and push the full project to GitHub (from /project).