For my Rails apps I normally deploy to production from a tagged version, and then display the tag in the user interface assigning the output of git describe --always to a variable in config/application.rb.
Now I'm moving an app over to Heroku, and deployment to heroku only happens using the master branch, so this trick won't work any more.
Are there any other ways to assign a version number to my code and display it on the UI when I've deployed to heroku?
Thanks,
Stewart
You can add a variable to the Heroku configuration by running this command locally whenever you push new changes to Heroku:
heroku config:add GIT_TAG=`git describe --always`
Then you can access this in your app's configuration:
version = ENV['GIT_TAG'] || `git describe --always`
When the app is running on Heroku, it will pick up the config variable (ENV['GIT_TAG']) and when it's running locally in development it will fall back to running git describe --always.
You will need to update the Heroku config variable each time you deploy, but I generally add this kind of thing to a deploy script or rake task (along with useful things like creating a new tag marking the deploy and running any new database migrations on Heroku).
Doesn't git tag fit your needs?
And why wouldn't the old trick work anymore?
If you want to display it on the UI then a git SHA output probably isn't particularly useful - you have two options, set a Heroku config variable with a user friendly version number in or a set a version number in your code that you increment when you deploy from master. You could probably wrap the deploy up in a rake task that incremented the version number either a file (and then readded it to git and commits it) or simply increments a value in a config variable.
Also, don't forget Heroku release management http://blog.heroku.com/archives/2010/11/17/releases/ which you may also be able to employ here to get the version number from that perhaps.
Related
Is it possible to delete old builds in Gitlab CI?
I tested a few things and have now about 20 builds that are useless (most are failed anyway).
It also shows stages that I don't have anymore which kinda clutters the Pipelines page and some of the uploaded artifacts are a bit big.
I wasn't able to find any documentation on this, only that disabling CI in the settings doesn't remove the builds.
Using Gitlab 8.10 Community (hosted by Gitlab.com)
There is currently no option in the GUI to completely get rid of a build other than expunge related data from the build. (The erase option in the build)
If you would have a local installation you could modify the database directly but I would advise caution. (I'll put the guide here for completeness sake)
Login to the GitLab database. If you use the default PostgreSQL :
sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production
Check if there is a table ci_builds. For pSQL: \dt
Delete the builds with normal SQL. For example: DELETE FROM ci_builds WHERE id = 2
(Optional) If you want to cleanup a list of commits which triggered a build you need to midify the table ci_commits.
I have created a new custom cartridge, in which I have packaged into an rpm using tito and installed using yum. This cartridge is being copied from my spec file to the /usr/libexec/openshift/cartridges directory, however, when I log into the origin home site and try to create an application my cartridge does not show up. I went digging in the ruby scripts and I found that there is a script named cartridge_cache.rb seems to be caching the cartridges it finds within the /usr/libexec/openshift/cartridges directory. I have tried to get origin to reload the cache to include my new cartridge by removing all the cache files within the /var/www/openshift/broker/cache directory then restarting the broker, but I have had no success. Is there somewhere I need to hardcode my cart name to some global variable or something ? Basically, Does anyone know how to get your custom cart to show up on the webpage for creating a new application.
UPDATE: So I ran into a slide deck that had one slide on how to install the cartridge. However, I still have had no success, but here is what I have tried since the previous post:
moved my cartridge directory from /usr/libexec/openshift/cartridges to /usr/libexec/openshift/catridges/v2
ran this command
oo-admin-cartridge -a install -s /usr/libexec/openshift/cartridges/v2/myfirstcart
which the output stated it installed the cartridge.
cleared cache with
bundle exec rake tmp:clear
restarted the openshift broker service
Also, just to make sure the cache was cleared out I went into the Rails console and ran Rails.cache.clear. And still no custom cartridge on the openshift webpage.
It works for me after cleaning cache
cd /var/www/openshift/broker
bundle exec rake tmp:clear
and restarting broker service
service openshift-broker restart
http://openshift.github.io/documentation/oo_administration_guide.html#clear-the-broker-application-cache
MCollective service on Node server (if you have separate servers for broker and node) must be restarted. e.g. with
service ruby193-mcollective restart
After that you should clear the caches on broker server e.g with
/usr/sbin/oo-admin-broker-cache --console
Then you should have new cartridges available
I am having a memory leak and am trying to track it down, therefore im trying to use oink on Heroku servers. Since Heroku does not provide log archives, im exporting them to Amazon S3 through the Papertrail add-on.
I have been able to succesfully do so, however, in order to use oink, my log files must be in a special format called "Hodel 3000 compliant logger". I have managed to do so in development, however I do not know how to create such log files in production (*heroku). Any help would be appreciated.
Thanks in advance,
Juan Lagrange
The hodel_3000_compliant_logger gem should do the job here; it's designed just for that purpose.
Add gem 'hodel_3000_compliant_logger' to your Gemfile, then bundle install
Add config.logger = Hodel3000CompliantLogger.new(config.paths['log'].first) to your application.rb (if you want to replace your default logger with the Hodel3000 one).
I'm deploying to servers with capistrano and doing a bundle exec rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile as the last step. Problem is when it gets to this point FROM cap deploy, i get the following error:
/usr/local/rvm/gems/ruby-1.9.3-p194/gems/bundler-1.1.4/lib/bundler/spec_set.rb:90:in `block in materialize': Could not find Platform-0.4.0 in any of the sources (Bundler::GemNotFound)
Platform-0.4.0 IS in fact on the server. And when i go into the server and run this exact command, all works great.
Couple of facts about my server: its using RVM, but that doesn't seem to be an issue with cap as the stack trace above would suggest. The other fact of interest is that this server was first created with a custom script I wrote that downloads an archived version of the git repo and then manually runs what cap does on a deploy. The reason I'm doing this, if anyone asks, is for automation with AWS AutoScaling. If i do a normal deploy:setup (not using my AWS script), it works fine with deployments. But the gem list is the same, and the site works all the same either way. Its just something with the cap deploy
Any thoughts?
I figured out what I was doing wrong. on my custom AMI scripts, i was naming the initial release folder 'first' when it should be a timestamp the way capistrano normally names it. That screwed things up on subsequent deployments.
I just downloaded the free trial of Bamboo continuous integration server, and created the first plan with nothing but downloading the source code from the git. I have a local git repository on the bamboo machine so the git URL is pointing to a local path.
The problem is that when I run the job, it never finishes even after waiting for an hour. This is the last lines of the activity log:
07-Apr-2011 20:03:23 Checking out revision f9dc82500914333ed4bbdae5ed038771fd658c3c.
07-Apr-2011 20:03:23 Creating local git repository in '/home/bob/bamboo-home/xml-data/build-dir/DEV-DEV-1/.git'.
From the shell I can go to the directory shown in the log and see that the source code were cloned correctly to the bamboo working directory. But the job will never finish and the log will not have any more update from here. I have to manually terminate the job. Any ideas? Do I miss something?
Just a guess, since the Bamboo instance we have at work pulls from Accurev and not Git, and I've never run into this problem myself - but it may be hung because there isn't a builder defined for that plan. You might try defining a builder (even if it's one that you know will fail) just to see if it makes it to that next step.
I had very similar problem.
It's not very original solution but I just uninstalled bamboo and installed it again.. Now it works now