I'm trying to get the PHP Tidy extension to run on my Heroku instance that I've set up. I've added ext-tidy to my composer.json file and run composer update to update the composer.lock file.
However when I push the changes to Heroku, the build fails as the Heroku buildpack doesn't include the Tidy extension.
Is there a way to get Composer to bundle the Tidy extension so that it gets pushed to Heroku (I'm using a Windows machine so I don't know if this will complicate matters if it is possible)? Or do I need to create a new buildpack with Tidy integrated? If so, I'd appreciate it if someone could point me in the right direction to be able to do this.
Thanks.
Related
Problem
I was facing difficulty in importing one of the packages properly and using it in my MERN application in the backend. After researching and looking at the deployed code I got to know that my application is using the unwanted version of that package and thus it is causing the issue but I already changed the version in package.json before pushing. I have written unwanted here because in my case the new version of the package has bugs and that's why I want the old/previous version back but I am unable to know the exact reason or thing which is causing heroku to use the unwanted version again and again.
For Clarity:
initial version: 1.6.6 (was working fine)
then I installed version: 1.7.0 (found bugs) unwanted version
tried to go back to version: 1.6.6 but couldn't
What I have tried
The first thing I tried was setting NODE_MODULES_CACHE to false to avoid heroku from picking up old code as it has worked for me in the past. Apart from that I have I can't find any other thing.
There is nothing suspicious in the heroku logs and it builds the application without any error.
I found the solution to it if someone's looking for it. It is not much of a solution instead it's more about how heroku works.
Heroku uses npm ci instead of npm install.
npm ci installs all dependencies in respect to package-lock.json similar to npm install. The key difference here is that ci doesn't alter package-lock.json under any circumstances.
So basically, the package-lock.json was still the unwanted one in my case and heroku was installing that rather than what I pushed into package.json as it didn't matter.
So, in order to solve this issue you have two options:
You can push your updated package-lock.json. In my case I had intentionally not added package-lock.json to versioning as I thought heroku would update it so I had put it in .gitignore
You can set the USE_NPM_INSTALL environment variable to true to let Heroku know that you want to use npm install instead of npm ci to create the build environment. (NOTE: If you want to use npm install Heroku advises to use NODE_MODULES_CACHE=false as it speeds up the build time)
I went with option 1.
Link to Heroku docs: https://devcenter.heroku.com/articles/nodejs-support
I've been trying to set up migrations for a golang application on Heroku. I'm using native Go modules (vgo) and the official Heroku build pack. For migrations I'm using the migrate package.
The thing is, I could run migrations when the main function runs, but it feels a bit hacky, this would mean that every time the app restarts it will run the migrations. I would prefer to just run the schema migration when deploying.
I'm not sure how this can be accomplished, when I log in to the instance the go binary is not installed, it's like the build pack only executes the main function.
I could live with doing it with a Heroku CLI command but I can't find how to do this in the docs nor via Google.
All of your dependencies should be defined such that Heroku can install them for you. For Go, Heroku supports godep and govendor. If you're not already using one, pick one and start.
Your dependency file should be committed to your repository. For godep that's Godeps/Godeps.json and for govendor it's vendor/vendor.json. Your dependencies themselves should not be committed.
After you've added a dependency on migrate it should be available on Heroku. You can run migrate up and other commands via heroku run bash. Once you're comfortable running migrations manually you might want to consider adding a release phase command to your Procfile so migrations get applied automatically when you deploy a new version.
The documentation here says that heroku with pre-compile assets during deployement in Rails4.
However ,
I dont see the precompile assets message.
Using thin (1.6.1)
Using twitter-bootstrap-rails (2.2.8)
Using uglifier (2.3.1)
Using will_paginate (3.0.4)
Your bundle is complete! It was installed into ./vendor/bundle
Bundle completed (1.37s)
Cleaning up the bundler cache.
-----> Writing config/database.yml to read from DATABASE_URL
Detected manifest file, assuming assets were compiled locally
-----> Discovering process types
Procfile declares types -> (none)
Default types for Ruby -> console, rake, web, worker
I am facing issues with bootstrap in my app, where the nav bar wont load properly + some other nuances and I think its the asset precompile issue.
I am using Rails4, Ruby2.0
I have assets enabled in application.rb
config.assets.enabled = true
Precompiling manually did not help
heroku run rake assets:precompile
Had this same problem. I had precompiled locally for some reason and then pushed to Heroku.
Saw Heroku give the line "Detected manifest file, assuming assets were compiled locally" which made me realize it wasn't precompiling all the things.
When I did a "git add ." and committed, I saw that it was adding a bunch of public files. Pushing that to Heroku got it to work. So I had to precompile and git add everytime, basically doing Heroku's work for it and making a mess in my public folder. It got the job done, but was a poor fix.
I looked for the "manifest" that heroku mentioned and eventually found a ".sprockets-manifest..." file in the public directory.
Deleted that and Heroku was once again my friend.
Found this question as part of my research so I thought I'd share what I found in case anyone else sees this, or has any elaborational thoughts.
Now I have to go and see if .sprockets-manifest was important to anything else ....
I struggled with the asset pipeline for a while. There seems to be a bit of confusion as to how the asset pipeline works among newer Rubyists. In my experience, this is my workflow to the asset pipeline for Heroku.
Make sure that assets work locally on localhost (required for Heroku)
Delete the public/assets folder in the Rails directory with rm -rf ./public/assets
Make a new assets directory with mkdir public/assets
Run the rake assets:precompile command
You should see a list of assets being precompiled in your command line
Once assets are precompiled, you should commit the changes via the following commands: git add -A then git commit -am "commit message goes here"
Finally, push to heroku via git push heroku master
NOTE: This bears repeating -- make sure your assets work normally on localhost before pushing to Heroku.
Deleting the public/assets folder helped. Also I ran heroku run rake assets:clean.
After that I could see:
----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
Running: rake assets:precompile
The navbar loads fine now !
The message Detected manifest file, assuming assets were compiled locally is shown if there is .sprockets-manifest-*.json or manifest-*.json in public assets. So either removing individual file or whole public/assets works.
The source code for buildpack is here
I have created one application using NodeJS, Angular and Express which I want to run at Heroku. Now, Im using Grunt to build the code that are placed in the dist folder and is ready to be deployed and run on Heroku. This would be done by pushing the dist folder in the Heroku git repo.
Now, should i push my source code in Heroku git as well?
If so, how should I seperate it from dist-folder repository? For instance, I dont want Heroku to run npm install each time i push changes to remote repo. And dist folder should not be part of the source code folder in the repository since it is auto generated.
Using a git repository is the only way to push changes to heroku. So yes it is mandatory. Having said that here is what they have to say about it.
Heroku provides the git service primarily for deployment, and the ability to clone from it is offered as a convenience. We strongly recommend you store your code in another git repository such as GitHub and treat that as canonical.
Again there is no way to stop them from doing an npm install on each push. Here is a quote from their getting started guide
Heroku recognizes an app as Node.js by the existence of a package.json. Even if your app has no dependencies, you should still create a package.json that declares a name, version, and empty dependencies in order that it appear as a Node app.
But I suppose that you could download all the dependencies of your app locally, not specify in package.json, push it along with rest of your application and you might trick heroku into thinking that there are no dependencies. Have not tried it myself though.
If you don't want dist folder to be a part of push simply gitignore it.
I want to update one of my gems on staging server ONLY. So, I'm running
bundle update gemname
or
bundle install
but then I got error:
You have modified your Gemfile in development but did not check the resulting snapshot (Gemfile.lock) into version control
The problem is that I can't do it locally and I can't push it into git repository. Any ideas how to solve it?
OK, my problem was specific and quite rare, because I could't deploy app with new features due to situation with my client. Maybe it sounds awful, but at first I got to locally update my Gemfile, run bundle install, manually copy Gemfile.lock to my server and after all I could update gems as I want to. It works at now and when I will be allowed to deploy whole app code with capistrano, everything will be fine.
You can create groups in your Gemfile like this in your case:
group :staging do
gem 'gem_name', 'gem_version'
end
Only put the gems that you want to use in that specific environment.
Hope this helps :)