orbit-db/.circleci/config.yml
Mark Henderson 47a18b05f5 dev:updating keystore in package.json to git branch
pointing to fix/store-performance branch

fix:typo

fix: indentation

test: Changing test to reflect new orbit-store default

Update package.json

test: updating tests

update localstorage-level-migration dep

experiment:Moving keystore up ALL way

orbitdb storage adapter mark 1

fix: more passing tests

more fixes

chore:package-lock.json

reverting mkdir.c for now

package-lock.json for node 10.13

fix: circleci

fix: webpack fs updates

disabling loadCache

Moving storage adapter to its own thing

tests: fixing up

chore: long needed fixing

More linting

tests: fix up look sharp

test: v0 failure only

Reversting lint fixes

fix v0-load test

set cache heads

fix: passing in storage no longer needed

fix: removing artifact from previous merge

fix: honor default keystore and pesky call-by-reference bug

fix: removing directory arg from _addManifestToCache

chore: package-lock

fix: pending drop test

removing directory option for individual dbs

docs: removing directory options

fix: removing line instead of commenting

fix: moving storage setup to createInstance

feat: Upgrading ipfs to 0.36

chore: package-log

fix: restoring onlyHash

workaround: removing memstore from replication tests

fix: this.keystore.close and this.cache.close

chore: removing eslint annotation

chore: package-lock.json

fix: passing preCreate in as option

chore: package files

Fixing package.json

fixing replicate tests

Fixing some tests

Updating orbit-db-store dependency

CircleCI updates - To be obviated via other PR

Restoring ability to pass a custom directory to orbitdb.create

More test fixes

set identity tests fixed

Fixing replication tests

Temporarily disabling concurrency tests

Closing keystore in identities test

Restoring test:all

package.json

More replicate test fixes

successful make rebuild

Linting fixes
2019-08-30 14:18:28 -04:00

84 lines
4.9 KiB
YAML

# This configuration was automatically generated from a CircleCI 1.0 config.
# It should include any build commands you had along with commands that CircleCI
# inferred from your project structure. We strongly recommend you read all the
# comments in this file to understand the structure of CircleCI 2.0, as the idiom
# for configuration has changed substantially in 2.0 to allow arbitrary jobs rather
# than the prescribed lifecycle of 1.0. In general, we recommend using this generated
# configuration as a reference rather than using it in production, though in most
# cases it should duplicate the execution of your original 1.0 config.
version: 2
jobs:
build:
working_directory: ~/orbitdb/orbit-db
parallelism: 1
shell: /bin/bash --login
# CircleCI 2.0 does not support environment variables that refer to each other the same way as 1.0 did.
# If any of these refer to each other, rewrite them so that they don't or see https://circleci.com/docs/2.0/env-vars/#interpolating-environment-variables-to-set-other-environment-variables .
environment:
CIRCLE_ARTIFACTS: /tmp/circleci-artifacts
CIRCLE_TEST_REPORTS: /tmp/circleci-test-results
# In CircleCI 1.0 we used a pre-configured image with a large number of languages and other packages.
# In CircleCI 2.0 you can now specify your own image, or use one of our pre-configured images.
# The following configuration line tells CircleCI to use the specified docker image as the runtime environment for you job.
# We have selected a pre-built image that mirrors the build environment we use on
# the 1.0 platform, but we recommend you choose an image more tailored to the needs
# of each job. For more information on choosing an image (or alternatively using a
# VM instead of a container) see https://circleci.com/docs/2.0/executor-types/
# To see the list of pre-built images that CircleCI provides for most common languages see
# https://circleci.com/docs/2.0/circleci-images/
docker:
- image: circleci/node:10-browsers
steps:
# Machine Setup
# If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
# The following `checkout` command checks out your code to your working directory. In 1.0 we did this implicitly. In 2.0 you can choose where in the course of a job your code should be checked out.
- checkout
# Prepare for artifact and test results collection equivalent to how it was done on 1.0.
# In many cases you can simplify this from what is generated here.
# 'See docs on artifact collection here https://circleci.com/docs/2.0/artifacts/'
- run: mkdir -p $CIRCLE_ARTIFACTS $CIRCLE_TEST_REPORTS
# This is based on your 1.0 configuration file or project settings
# Dependencies
# This would typically go in either a build or a build-and-test job when using workflows
# Restore the dependency cache
# - restore_cache:
# keys:
# # This branch if available
# - v1-dep-{{ .Branch }}-
# # Default branch if not
# - v1-dep-master-
# # Any branch if there are none on the default branch - this should be unnecessary if you have your default branch configured correctly
# - v1-dep-
# The following line was run implicitly in your 1.0 builds based on what CircleCI inferred about the structure of your project. In 2.0 you need to be explicit about which commands should be run. In some cases you can discard inferred commands if they are not relevant to your project.
- run: if [ -z "${NODE_ENV:-}" ]; then export NODE_ENV=test; fi
- run: export PATH="~/orbitdb/orbit-db/node_modules/.bin:$PATH"
- run: make rebuild
# Save dependency cache
# - save_cache:
# key: v1-dep-{{ .Branch }}-{{ epoch }}
# paths:
# # This is a broad list of cache paths to include many possible development environments
# # You can probably delete some of these entries
# - vendor/bundle
# - ~/virtualenvs
# - ~/.m2
# - ~/.ivy2
# - ~/.bundle
# - ~/.go_workspace
# - ~/.gradle
# - ~/.cache/bower
# - ./node_modules
# Test
# This would typically be a build job when using workflows, possibly combined with build
# The following line was run implicitly in your 1.0 builds based on what CircleCI inferred about the structure of your project. In 2.0 you need to be explicit about which commands should be run. In some cases you can discard inferred commands if they are not relevant to your project.
# Teardown
# If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
# Save test results
- store_test_results:
path: /tmp/circleci-test-results
# Save artifacts
- store_artifacts:
path: /tmp/circleci-artifacts
- store_artifacts:
path: /tmp/circleci-test-results