Basically, I don't want pipeline step clone code on next steps, only first step will clone the source code a time. Another reason is if step clone the source code (and doesn't use the source code from previous) the built code will be lost.
I known that the bitbucket pipeline has the artifacts feature but seems it only store some parts of the source code.
The flow is:
Step 1: Clone source code.
Step 2: Run in parallel two steps, one install node modules at root folder, one install node module and build js, css at app folder.
Step 3: Will deploy the built source code from step 2.
Here is my bitbucket-pipelines.yml
image: node:11.15.0
pipelines:
default:
- step:
name: Build and Test
script:
- echo "Cloning..."
artifacts:
- ./**
- parallel:
- step:
name: Install build
clone:
enabled: false
caches:
- build
script:
- npm install
- step:
name: Install app
clone:
enabled: false
caches:
- app
script:
- cd app
- npm install
- npm run lint
- npm run build
- step:
name: Deploy
clone:
enabled: false
caches:
- build
script:
- node ./bin/deploy
definitions:
caches:
app: ./app/node_modules
build: ./node_modules
After research hundred pages but cannot find anything, then I must try one by one by myself, finally I found the pattern for the artifacts of all the files:
artifacts:
- '**'
Related
I'm trying to set up a pipeline in Bitbucket with a daily schedule for two branches.
develop : There a scheduled daily deployment running + when I push to this branch the pipeline runs again
master : This is the tricky one. I want to have a daily deployment because the page need to be rebuild daily, but I would like to have a security that if anyone pushes to this branch by mistake or the code is bad, it only runs the deployment after a manual trigger.
So my question is that is it possible to set up a rule to track if there was a push and in this case let the admin manually start the pipeline ?
pipelines:
branches:
develop:
- step:
name: Deploy staging
deployment: staging
caches:
- node
script:
- npm run staging:auto
- npm install firebase
- npm install firebase-functions
- npm install -g firebase-tools
- firebase deploy --token=$FIREBASE_TOKEN --project $FIREBASE_PROJECT_STAGING --only functions,hosting
artifacts:
- build/**
master:
- step:
name: Deploy to production
deployment: production
caches:
- node
script:
- npm run deploy:auto
- npm install firebase
- npm install firebase-functions
- npm install -g firebase-tools
- firebase deploy --token=$FIREBASE_TOKEN_STAGING --project $FIREBASE_PROJECT_PRODUCTION --only functions,hosting
artifacts:
- build/** ```
I'd suggest to schedule a different custom pipeline other than the one that runs on pushes to the production branch. The same steps definition can be reused with a yaml anchor and you can replace the trigger in one of them.
E.g:
definitions:
# write whatever is meaningful to you,
# just avoid "caches" or "services" or
# anything bitbucket-pipelines could expect
yaml-anchors:
- &deploy-pro-step
name: Deploy production
trigger: manual
deployment: production
script:
- do your thing
pipelines:
custom:
deploy-pro-scheduled:
- step:
<<: *deploy-pro-step
trigger: automatic
branches:
release/production:
- step: *deploy-pro-step
Sorry if I make some yaml mistakes, but this should be the general idea. The branch where the scheduled custom pipeline will run is configured in the web interface when the schedule is set up.
We have a monorepo that contains about 5 projects. All these projects are build based on the git change history, so if project A is not changed, it is not build. This is al managed by Nx monorepo.
We are using Bitbucket Pipelines to build and deploy our projects. We want to split every deploy into it's own step so that we have more control over each project's deployment.
In order to achieve this we need to change our build step so that it only executes if the dist folder contains the portal it is ment to deploy. I've read about the condition configuration, but i cannot find anything about checking build artifacts in a condition instead of the git commit that triggerd the change. So is there a way to skip (or directly pass) a step if the portal is not in the build artifact?
Build step
- step: &build
name: Build
caches:
- node
script:
- git fetch origin master:refs/remotes/master
- npm run build
artifacts:
- dist/**
Example Dist artifact
.
├── dist/
│ ├── login-portal
│ ├── Portal-Y
Our deploy step
- step: &deployLoginPortal
image: amazon/aws-cli:2.4.17
deployment: test
trigger: manual
script:
- aws s3 sync $LOGIN_OUTPUT_PATH s3://$LOGIN_S3_BUCKET/ --acl public-read # Sync the portal
# $LOGIN_OUTPUT_PATH = 'dist/login-portal'
Example condition (does not work)
condition:
changesets:
includePaths:
- $LOGIN_OUTPUT_PATH/** # only run if dist contains changes in $LOGIN_BUILD_PATH
Am I missing something or is there an other way of only executing the step if the build artifact (dist/) contains the portal the step is ment to deploy?
You can manually check the presence of an artifact before doing aws s3 sync and gracefully exit the step if condition is not satisfied:
script:
- [ ! -d "$LOGIN_OUTPUT_PATH" ] && echo "Directory $LOGIN_OUTPUT_PATH is not present; gracefully exiting" && exit 0
- aws s3 sync $LOGIN_OUTPUT_PATH s3://$LOGIN_S3_BUCKET/ --acl public-read
Be advised that your step will still technically be triggered, so its startup time (usually about 40 seconds) will be affecting your quotas.
If I:
run a build in travis, and
tests pass correctly, but
there is some problem uploading coverage results to codecov,
...Travis goes ahead and deploys anyway. How can I stop travis from deploying in this case?
The deploy-regardless-of-upload-failure:
.
Here's my .travis.yml:
dist: trusty
language: python
python:
- '3.6'
# Install tox and codecov
install:
- pip install tox-travis
- pip install codecov
# Use tox to run tests in the matrix of environments
script:
- tox -r
# Push the results back to codecov
after_success:
- codecov --commit=$TRAVIS_COMMIT"
# Deploy updates on master to pypi, which will only succeed if there's been a version bump
deploy:
provider: pypi
skip_cleanup: true
skip_existing: true
user: me
password:
secure: "stuff"
on:
branch: master
According to this https://bitbucket.org/ned/coveragepy/issues/139/easy-check-for-a-certain-coverage-in-tests, if you add the --fail-under switch to the coverage report command, it will exit with a non-zero exit code (which travis will see as a failure) if the code coverage is below the given percentage.
That would make the script section of your .travis.yml file look like:
script
- coverage run --source="mytestmodule" setup.py test
- coverage report --fail-under=80
Of course you could replace 80 with whatever percentage you'd like.
I'm trying to create two different actions within travis.ci. The first action is to execute a script on every push on every branch. This is currently working as desired. The second is to trigger a different script only when git push origin --tags. In short:
Execute script1 always (currently working)
Execute script2 when tags are pushed
Here is what I'm trying:
language: python
python:
- 3.7
matrix:
include:
- python: 3.7
sudo: true
install:
- pip install -r requirements.txt
script: # Always want this to happen
- invoke package
branches:
only:
- master
- /^x\/.*/
deploy: # Want this to occur on git push origin --tags
provider: script
script: invoke release
on:
tags: true
The deploy section is not being triggered, and I can find no evidence of the invoke release script being invoked.
Update:
It may be due to the way I'm pushing tags..? I'm seeing this log in travis now:
Skipping a deployment with the script provider because this is not a tagged commit
Solved it from this github issue. Changed the deploy section to this:
deploy:
provider: script
script: invoke release
on:
tags: true
all_branches: true
but had to remove the branches section. Deployment script was invoked, nonetheless.
My .circleci/config.yml is:
# Javascript Node CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-javascript/ for more details
#
version: 2
jobs:
build:
docker:
# specify the version you desire here
- image: circleci/node:8.11.1
working_directory: ~/repo
steps:
- checkout
- restore_cache:
keys:
- v1-dependencies-{{ checksum "package.json" }}
# fallback to using the latest cache if no exact match is found
- v1-dependencies-
- run: yarn install
- save_cache:
paths:
- node_modules
key: v1-dependencies-{{ checksum "package.json" }}
# run tests!
- run:
command: yarn test
environment:
SOME: 'stuff'
This works well with github currently for my feature branches PR'ed against develop. I want to set up another workflow for when I have a PR of develop into master. I want to trigger the yarn integration script with different environment variables.
There's no built-in way to see the target/base branch of PR from within CircleCI. You'd need to create a GitHub personal token and do some scripting with their API in order to accomplish this.