Just mount a Gitlab in digitalocean to keep track of versions of some projects, but now I've read a little about Gitlab I wonder if you can set Gitlab CI so that each time you do a commit automatically make a build of application and if the build is successful can do a deploy to OpenShift.
I think my .gitlab-ci.yml should look something like this:
stages:
- build
- deploy
before_script:
- npm install
job_build:
stage: build
script:
- grunt build
job_deploy:
stage: deploy
But I really do not know if this is as valid and neither tell Gitlab CI must only make a git push to OpenShift repository.
After much reading and searching finally found documentation about this [1], in the end I have resolved some file using the following .gitlab-ci.yml
stages:
- build
- deploy
job_build:
stage: build
script:
- npm install -g grunt-cli
- npm rebuild node-sass
- npm install
- grunt build
job_deploy:
stage: deploy
script:
- apt-get update -yq
- apt-get install -y ruby-dev rubygems
- gem install dpl
- dpl --provider=openshift --user=$OPENSHIFT_USER --password=$OPENSHIFT_PASS --domain=mydomain --app=example
only:
- master
The magic happens with a Travis library call dpl [2] that supports a lot of providers [3]
[1]http://doc.gitlab.com/ce/ci/deployment/README.html
[2]https://github.com/travis-ci/dpl
[3]https://github.com/travis-ci/dpl#supported-providers
Related
Good Evening,
I am trying to implement Gitlab CI/CD using the Angular ng test command. The pipeline runs,
but hangs. I know Karma uses chrome. I am not sure what to add. Any help is appreciated thank you.
image: node:latest
before_script:
- apt-get update -qy
- apt-get install -y ruby-dev
- gem install dpl
- npm link #angular/cli
stages:
- test
- production
unit-test:
stage: test
image: trion/ng-cli-karma:${CLI_VERSION}
script:
- npm install
- ng test
only:
- master
production:
type: deploy
stage: production
image: ruby:latest
script:
- dpl --provider=heroku --app=$HEROKU_APP_PRODUCTION --api-key=$HEROKU_API_KEY
only:
- master
Do the tests run and then the pipeline hangs? If that is the case, I bet it is because ng test runs in watch mode and is always running looking for changes.
To fix it, change ng test to ng test --watch=false --browsers=ChromeHeadless.
I changed the browser to be headless Chrome as well (optional) and this should bring a slight increase in speed in your CI/CD
The flags can be found here.
I'm new to Continous Intregration and recently I setup my first project in CircleCI.
Unfortunately I seems like it's not completely working as expected.
I want to deploy my application to Firebase (Hosting and Functions).
Of course I added Environment Variables to the project in CircleCI.
But Firebase Functions doesn't access my Environment Variables so it's running into errors.
In the Functions folder I created a new nodejs application incl. the dotenv package and I'm calling the variables with process.env.CIRCLECI_VARIABLE.
Would be great if someone could give me a hint what's missing.
config.yml
version: 2.1
jobs:
build:
docker:
- image: circleci/node:10
steps:
- checkout
- run:
name: Install packages
command: yarn install
- run:
name: Build project
command: yarn build
- run:
name: Install functions packages
command: cd ./functions && yarn install
deploy:
docker:
- image: circleci/node:10
steps:
- checkout
- run:
name: Install packages
command: yarn install
- run:
name: Build project
command: yarn build
- run:
name: Install functions packages
command: cd ./functions && yarn install
- run:
name: Installing Firebase-Tools
command: yarn add firebase-tools
- run:
name: Firebase Deploy
command: ./node_modules/.bin/firebase deploy --token "$FIREBASE_TOKEN"
workflows:
build_and_deploy:
jobs:
- build
- deploy:
requires:
- build
filters:
branches:
only: master
I've found the solution
I didn't know that I have to add the Environment Variables to the Google Cloud Function.
Now everything is working as expected
I'm sure this is a common issue but I can't seem to find a definitive answer.
I have a node application which in order to build requires some devDependencies such as babel. In order to run my tests also requires devDependencies such as jest. But when CI runs in production environment, it obviously doesn't install any devDependencies so I get errors where the package isn't found.
What is the best practice for running builds and tests in prod without devDependencies?
If it helps, I am running my build in GitLab Pipelines:
image: node:8.11.2
stages:
- prepare
- test
- deploy
install_and_build:
stage: prepare
script:
- npm install yarn
- yarn
- yarn build
only:
- master
test:
stage: test
script:
- yarn test
only:
- master
deploy_production:
type: deploy
stage: deploy
image: ruby:latest
script:
- apt-get update -qy
- apt-get install -y ruby-dev
- gem install dpl
- dpl --provider=heroku --app=app-name --api-key=$HEROKU_API_KEY
only:
- master
From this answer,
You will want to follow have your process to the effect of the
following:
First, you need to "install with all dependencies".
npm install
Then do your tests.
npm test
Then "prune" your dev dependencies as below, as detailed in the
docs doing this
"will remove the packages specified in your devDependencies".
npm prune --production
I am deploying Django application using Gitlab CI/CD and pytest for testing of code and pytest-cov for generating coverage report
My .gitlab-ci.yml
stages:
- test
- deploy
image: python:3.6
test:
stage: test
script:
- pip install pipenv
- pipenv install
- pipenv run py.test src/
artifacts:
paths:
- htmlcov/
pages:
stage: deploy
dependencies:
- test
script:
- mv htmlcov/ public/
artifacts:
paths:
- public
expire_in: 30 days
only:
- master
staging:
stage: deploy
script:
- apt-get update -qy
- apt-get install -y ruby-dev
- gem install dpl
- dpl --provider=heroku --app=app-staging --api-key=$HEROKU_PRODUCTION_API_KEY
only:
- master
production:
stage: deploy
script:
- apt-get update -qy
- apt-get install -y ruby-dev
- gem install dpl
- dpl --provider=heroku --app=app-production --api-key=$HEROKU_PRODUCTION_API_KEY
when: manual
only:
- master
Since repository is under a group namespace, the url to the coverage report is
https://<group>.gitlab.io/<repository>/
For coverage report,
[](https://<group>.gitlab.io/<repository>/)
But this is displaying Unknown
I have setup Test Coverage parsing regex for python
I know this is an old question, but this may help others see this question in the future.
Except setting the Test Coverage parsing regex in the Settings, CI/CD page, you need to make sure the test coverage percent is printed somewhere in the CI's console log. The printed line should match the given regex. So, Gitlab can parse and save it as the code coverage percent.
I've answered with more detail the same question: Gitlab coverage badge always unknow
Your regex works for me in Gitlab.
I've had similar problems though, because just rerunning a job does not pick up new settings, and so you need to do a fresh commit to get the coverage to show up in the job output.
I'm using react-starter-kit for developing my web application, and Gitlab as my remote git repository.
I want to configure a continuous deployment such that on every push to the master, the npm run deploy script will be executed.
From my local pc, executing npm run deploy builds the node application and push it to the remote heroku git repository. It uses the local credentials on my pc.
I have configured the gitlab runner (in the .yml file) to execute the same npm run deploy, but it fails with Error: fatal: could not read Username for 'https://git.heroku.com': No such device or address.
I need to find a way to authenticate the gitlab runner to heroku. I have tried to set env variable HEROKU_API_KEY, but it also didn't work.
How can I push from my gitlab runner to my heroku git repo?
You should use dlp in your yml. Try something like this in the .gitlab-ci.yml:
before_script:
- apt-get -qq update
- npm set progress=false
- npm install --silent
deploy:
script:
- npm run deploy
- apt-get install -yqq ruby ruby-dev --silent
- gem install dpl
- dpl --provider=heroku --app=your-app-name --api-key=$HEROKU_API_KEY
only:
- master
You preferaby want to add the env variable $HEROKU_API_KEY from GitLab, not here directly.