Here is the error I get when the gitlab runner run my CI script:
pg_dump: server version: 13.2 (Debian 13.2-1.pgdg100+1); pg_dump version: 11.11 (Debian 11.11-0+deb10u1)
pg_dump: aborting because of server version mismatch
rails aborted!
failed to execute:
pg_dump -s -x -O -f /builds/steady-install-inc/steady-install-backend/db/structure.sql test
And here is the .gitlab-ci.yml file running rspec:
image: ruby:2.6.3
stages:
- test
- deploy
cache:
key: $CI_COMMIT_REF_SLUG
paths:
- vendor/bundle
before_script:
- gem install bundler
- bundle install --deployment --without development -j $(nproc)
rspec:
stage: test
services:
- postgres:13.2
variables:
POSTGRES_DB: test
POSTGRES_USER: test
POSTGRES_PASSWORD: test
DATABASE_URL: "postgres://$POSTGRES_USER:$POSTGRES_PASSWORD#postgres/$POSTGRES_DB"
DATABASE_CLEANER_ALLOW_REMOTE_DATABASE_URL: 'true'
script:
# Use example environment variables
- cp config/application.yml.example config/application.yml
- apt-get update -qy && apt-get install -y nodejs
- apt-get install -y postgresql postgresql-client libpq-dev
- bundle exec rails db:migrate RAILS_ENV=test
- bundle exec rspec
coverage: '/\(\d+.\d+\%\) covered/'
only:
- merge_requests
Can any see what I'm doing wrong?
I've tried around 5-10 suggestions online but most seemed to either be for unbuntu or docker which I'm not fully sure how to implement or they just didn't work.
Anything helps!
Edit:
I also forgot to mention I recently switched to a schema.rb format to a structure.sql format but I'. not sure if that is part of the problem as my specs pass when I run them locally.
I lack expertise with gitlab-ci.yml, but I wanted to mention Gitlab's CI Linter- have you tried that? It's kinda hidden. On the left menu choose CI/CD > Pipelines and it will be in the far right corner of the pipeline view.
Gitlab pipeline view with CI lint button
Related
I am trying to setup bitbucket pipeline for a php based (Laravel-Lumen) app intended to be deployed on nanobox.io. I want this pipeline to deploy my app as soon as code changes are committed.
My bitbucket-pipelines.yml looks like this
image: php:7.1.29
pipelines:
branches:
staging:
- step:
name: Publish to staging version
deployment: staging
caches:
- composer
script:
- apt-get update && apt-get install -y unzip
- curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
- composer install
# - vendor/bin/phpunit
- bash -c "$(curl -fsSL https://s3.amazonaws.com/tools.nanobox.io/bootstrap/ci.sh)"
- nanobox deploy
This gives Following error
+ nanobox deploy
Failed to validate provider - missing docker - exec: "docker": executable file not found in $PATH
Using nanobox with native requires tools that appear to not be available on your system.
docker
View these requirements at docs.nanobox.io/install
I then followed this page and changed second last line to look like this
sudo bash -c "$(curl -fsSL https://s3.amazonaws.com/tools.nanobox.io/bootstrap/ci.sh)"
when done that, I am getting following error
+ sudo bash -c "$(curl -fsSL https://s3.amazonaws.com/tools.nanobox.io/bootstrap/ci.sh)"
bash: sudo: command not found
I ran out of tricks here, also I don't have experience in this area. Any help is very much appreciated.
First, you can't use sudo in pipelines, but that's probably not relevant here. The issue is that nanobox cli wan't to execute docker, which isn't installed. You should enable the docker service for your step.
image: php:7.1.29
pipelines:
branches:
staging:
- step:
name: Publish to staging version
deployment: staging
# Enable docker service
services:
- docker
caches:
- composer
script:
- docker version
You might wan't to have a look at Pipelines docs as well: Run Docker commands in Bitbucket Pipelines
I'm trying to get a rails app to run on Circle CI. With the following configuration I can't seem to get anything to work at all. When I ssh in, I can't even run sudo.
Here's the error output:
install dependencies
$ #!/bin/bash -eo pipefail
bundler install --jobs=4 --retry=3 --path vendor/bundle
/bin/bash: bundler: command not found
Exited with code 127
I noticed there is nothing but assets/ under the vendor directory.
Here's my configuration file:
version: 2
jobs:
build:
working_directory: ~/repo
docker:
- image: circleci/postgres:9.6-alpine-postgis-ram
- image: circleci/ruby:2.3
environment:
PGHOST: 127.0.0.1
PGUSER: staging
RAILS_ENV: test
- image: circleci/postgres:10.5
environment:
POSTGRES_USER: staging
POSTGRES_DB: test
POSTGRES_PASSWORD: ""
steps:
- checkout
# Download and cache dependencies
- restore_cache:
keys:
- v1-dependencies-{{ checksum "Gemfile.lock" }}
# fallback to using the latest cache if no exact match is found
- v1-dependencies-
- run:
name: install dependencies
command: |
bundle install --jobs=4 --retry=3 --path vendor/bundle
- save_cache:
paths:
- ./vendor/bundle
key: v1-dependencies-{{ checksum "Gemfile.lock" }}
# Database setup
- run: bundle exec rake db:create
- run: bundle exec rake db:schema:load
# run tests!
- run:
name: run tests
command: |
mkdir /tmp/test-results
TEST_FILES="$(circleci tests glob "spec/**/*_spec.rb" | circleci tests split --split-by=timings)"
bundle exec rspec --format progress \
--format RspecJunitFormatter \
--out /tmp/test-results/rspec.xml \
--format progress \
$TEST_FILES
# collect reports
- store_test_results:
path: /tmp/test-results
- store_artifacts:
path: /tmp/test-results
destination: test-results
All help is appreciated, thanks!
Your commands are running on the postgres container because it is listed first. If you make the ruby container first, then you will have access to bundle. And then when you SSH, you will be inside of the ruby container.
https://circleci.com/docs/2.0/configuration-reference/#docker--machine--macosexecutor
The first image listed in the file defines the primary container image where all steps will run.
Relevant lines of my .travis.yml file, which I got from the sample here:
https://docs.codeclimate.com/v1.0/docs/travis-ci-test-coverage
env:
global:
- CC_TEST_REPORTER_ID=MY_ACTUAL_ID
services:
- postgresql
before_script:
- curl -L https://codeclimate.com/downloads/test-reporter/test-reporter-latest-darwin-amd64 > ./cc-test-reporter
- chmod +x ./cc-test-reporter
- ./cc-test-reporter before-build
- psql -c 'create database travis_ci_test;' -U postgres
script:
- bundle exec rake db:migrate
- bundle exec rspec
after_script:
- ./cc-test-reporter after-build --exit-code $TRAVIS_TEST_RESULT
Error:
$ ./cc-test-reporter before-build
/home/travis/.travis/job_stages: line 57: ./cc-test-reporter: cannot execute binary file: Exec format error
The command "./cc-test-reporter before-build" failed and exited with 126 during .
Thanks
Solved:
I realized that while my development machine may be MacOS, the TravisCI environment is on Linux.
Changing test-reporter URL to https://codeclimate.com/downloads/test-reporter/test-reporter-latest-linux-amd64 did the trick!
The latest version 0.9.0 on linux is throwing the same format error.
The executable has been compiled incorrectly.
As a workaround you can use the previous version:
curl -L https://codeclimate.com/downloads/test-reporter/test-reporter-0.7.0-linux-amd64 > ./cc-test-reporter
I realized that while my development machine may be MacOS, the TravisCI environment is on Linux.
Changing test-reporter URL to https://codeclimate.com/downloads/test-reporter/test-reporter-latest-linux-amd64 did the trick!
I added an additional container in circle ci and tried to run tests parallaly.
This is my circle.yml file.
machine:
ruby:
version: 2.3.0
database:
post:
- cp config/sunspot.ci.yml config/sunspot.yml
- bundle exec sunspot-solr start -p 8981
dependencies:
pre:
- sudo apt-get update; sudo apt-get -y install solr-tomcat
test:
override:
- rvm use 2.3.0 && bundle exec rspec --color --format progress:
environment:
RAILS_ENV: test
parallel: true
files:
- "spec/**/*_spec.rb"
but tests don't seem to be running in parallel.
What am I missing? Thanks in advance
For some reason removing rvm use 2.3.0 from test section fixed my problem.
machine:
ruby:
version: 2.3.0
database:
# After default database task finished
post:
# Circle CI already replace our original sunspot.yml, replace it with backup copy `config/sunspot.yml.ci`
- cp config/sunspot.ci.yml config/sunspot.yml
- bundle exec sunspot-solr start -p 8981
dependencies:
pre:
- sudo apt-get update; sudo apt-get -y install solr-tomcat
test:
override:
- bundle exec rspec --tag ~#flaky --color --profile 20 --format progress:
timeout: 240
environment:
RAILS_ENV: test
parallel: true
files:
- my files here
I have a Rails App hosted on gitlab.com, and I am configuring it to deploy to heroku following this guide: http://docs.gitlab.com/ce/ci/examples/test-and-deploy-ruby-application-to-heroku.html. It works fine.
My question is, how can I run migrations every time I deploy to heroku? When deploying via CLI I would usually do:
git push heroku master && heroku run rake db:migrate
but using gitlab-ci.yml I have no clue on how to do this...
If you want to be able to use the full power of the Heroku CLI in your GitLab CI process (including having the build fail if a migration fails for whichever reason), you can also try this approach which will install the Heroku CLI and deliver status codes of your Heroku commands back to GitLab, as well as, of course, the command line output. Using heroku run without credentials on the commandline require the HEROKU_API_KEY environment variable to be set to a key which has access to the app in question.
before_script:
- echo "deb http://toolbelt.heroku.com/ubuntu ./" > /etc/apt/sources.list.d/heroku.list
- wget -O- https://toolbelt.heroku.com/apt/release.key | apt-key add -
- apt-get update
- apt-get install -y heroku-toolbelt
- gem install dpl
stages:
- deploy
test_on_heroku:
type: deploy
script:
- dpl --provider=heroku --app=my_heroku_app --api-key=$HEROKU_API_KEY
- heroku run <your command here> --exit-code --app my_heroku_app
I actually run my tests on an Heroku instance to be sure, the environment is exactly the same. This is where this comes in real handy.
The information in this answer may be out of date. Please see both answers below, and remember to upvote the answers that are up to date to help future visitors.
here is a sample .yml I have that runs my tests then pushed to Heroku stage (for master branch pushes) or production (for tags pushes)
image: "ruby:2.3"
test:
script:
- apt-get update -qy
- apt-get install -y nodejs
- gem install bundler
- bundle install -j $(nproc) --without production
- bundle exec rails db:create RAILS_ENV=test
- bundle exec rails db:migrate RAILS_ENV=test
- bundle exec rails RAILS_ENV=test
staging:
type: deploy
environment: staging
script:
- gem install dpl
- dpl --provider=heroku --app=$HEROKU_STAGING_APP_NAME --api-key=$HEROKU_API_KEY
- "curl -n -X POST https://api.heroku.com/apps/$HEROKU_STAGING_APP_NAME/ps -H \"Accept: application/json\" -H \"Authorization: Bearer ${HEROKU_API_KEY}\" -d \"command=bundle exec rails db:migrate\""
only:
- master
production:
type: deploy
environment: production
script:
- gem install dpl
- dpl --provider=heroku --app=$HEROKU_PRODUCTION_APP_NAME --api-key=$HEROKU_API_KEY
- "curl -n -X POST https://api.heroku.com/apps/$HEROKU_PRODUCTION_APP_NAME/ps -H \"Accept: application/json\" -H \"Authorization: Bearer ${HEROKU_API_KEY}\" -d \"command=bundle exec rails db:migrate\""
only:
- tags
To update #huesforalice's answer, this would also work for the new Heroku CLI, which replaced Heroku Toolbelt in November 2016:
before_script:
- apt-get update
- apt-get install apt-transport-https
- echo "deb https://cli-assets.heroku.com/branches/stable/apt ./" > /etc/apt/sources.list.d/heroku.list
- wget -O- https://cli-assets.heroku.com/apt/release.key | apt-key add -
- apt-get update
- apt-get install -y heroku
- gem install dpl
staging:
type: deploy
variables:
HEROKU_API_KEY: $HEROKU_STAGING_API_KEY
script:
- dpl --provider=heroku --app=$HEROKU_STAGING_APP --api-key=$HEROKU_STAGING_API_KEY
- heroku run rails db:migrate --exit-code --app $HEROKU_STAGING_APP
only:
- master
production:
type: deploy
variables:
HEROKU_API_KEY: $HEROKU_PRODUCTION_API_KEY
script:
- dpl --provider=heroku --app=$HEROKU_PRODUCTION_APP --api-key=$HEROKU_PRODUCTION_API_KEY
- heroku run rails db:migrate --exit-code --app $HEROKU_PRODUCTION_APP
only:
- tags
To further improve #huesforalice and #Jimmy Bosse 's answers - If you want to
avoid putting Heroku CLI installation in the global before_script but only use it in the deployment stages
at the same time, avoid copying and pasting the installation snippet into different stages
You can do something like this using YAML anchors to DRY up
before_script:
# the global before_script
- gem install bundler --no-document
- bundle check || bundle install --jobs $(nproc)
.deployment_before_script: &deployment_before_script
before_script:
- echo "deb http://toolbelt.heroku.com/ubuntu ./" > /etc/apt/sources.list.d/heroku.list
- wget -O- https://toolbelt.heroku.com/apt/release.key | apt-key add -
- apt-get update
- apt-get install -y heroku-toolbelt
- gem install dpl
# other stages...
staging:
stage: deploy
<<: *deployment_before_script
script:
- dpl --provider=heroku --app=$HEROKU_APP_STAGING --api-key=$HEROKU_API_KEY_STAGING
- heroku run bundle exec rails db:migrate --exit-code --app $HEROKU_APP_STAGING
only:
- master
production:
stage: deploy
<<: *deployment_before_script
script:
- dpl --provider=heroku --app=$HEROKU_APP_PRODUCTION --api-key=$HEROKU_API_KEY_STAGING
- heroku run bundle exec rails db:migrate --exit-code --app $HEROKU_APP_PRODUCTION
when: manual
only:
- tags