Releases: openlawteam/openlaw-core
Releases · openlawteam/openlaw-core
v0.1.34
v0.1.33
v0.1.32
v0.1.31
Erc712 (#131) * update dependency add "method" property in ethereum call * new init execution for actions erc712 oracle * modify ethereum call class * update classes for ERC712 integration * New build environment, and CI test environments (#99) An experimental branch for us to mess with us using the scala-builder Docker image and rationalizing a proposed automated release process. - A new Dockerfile, based on `openlaw/scala-builder`, that builds the compiled environment for ol-core only (which in this project, is used for running tests or making a release). This image builds the dependencies first so that they can be cached. - A `/scripts` folder containing scripts that are responsible for running any CI process. Most of these are currently just wrappers around sbt commands, but enable us to more easily see what is possible, define requirements, and potentially move some steps out of sbt control in the future if needed. - Experimental test, coverage, and release stage integration for the following hosted CI environments: - CircleCI (build cached on Docker Hub), see `.semaphore` dir - SemaphoreCI (build cached in AWS EU region), see `.circleci` dir - Github Actions (build cached on Docker Hub), see `.github` dir All three CI environments will do a layer cached build, run tests and coverage reports in parallel with failFast reporting (coverage report is inclusive of tests but takes 2.5x longer to run, so we prefer faster failure). Note from this PR the following were excluded: - JenkinsX (too unstable, config archived in builder-jenkinsx branch) - Google Cloud Build (requires $ and will build if any Dockerfile present, so in different repo for now to avoid auto-triggering while we test). While all are configured, to avoid collisions, only one will do the actual pushing of coverage reports to Codacy and releases to BinTray. This is controlled via env var flags. In the future, we will pick one and optimize (including likely upgrading machine class for faster builders), but for now the goal is just to get the automated flow working with the new images, and we can have real world comparison to discuss. Since we are making major changes to our general develop/branching/release process, the goal is to get this integrated with the release flag *disabled*, and do manual releases using the new scripts for a bit. However, all the CI environments should be triggered in the background, and will do everything up to but excluding the final push to BinTray, giving us the flexibility to see how it is operating on real world data, so we can debug and tune before making it the default, and getting us familiar with the new branch model. Docs related to the current manual release process are in draft here: https://github.com/openlawteam/openlaw-core/pull/123 * WIP adding an "own version" * fix ERC712 if multiple signatories * implement OLOwnType * added variable name filtering for ERC712 signing * added OLInfo type to get contractId (and other info maybe later)
v0.1.30
New build environment, and CI test environments (#99) An experimental branch for us to mess with us using the scala-builder Docker image and rationalizing a proposed automated release process. - A new Dockerfile, based on `openlaw/scala-builder`, that builds the compiled environment for ol-core only (which in this project, is used for running tests or making a release). This image builds the dependencies first so that they can be cached. - A `/scripts` folder containing scripts that are responsible for running any CI process. Most of these are currently just wrappers around sbt commands, but enable us to more easily see what is possible, define requirements, and potentially move some steps out of sbt control in the future if needed. - Experimental test, coverage, and release stage integration for the following hosted CI environments: - CircleCI (build cached on Docker Hub), see `.semaphore` dir - SemaphoreCI (build cached in AWS EU region), see `.circleci` dir - Github Actions (build cached on Docker Hub), see `.github` dir All three CI environments will do a layer cached build, run tests and coverage reports in parallel with failFast reporting (coverage report is inclusive of tests but takes 2.5x longer to run, so we prefer faster failure). Note from this PR the following were excluded: - JenkinsX (too unstable, config archived in builder-jenkinsx branch) - Google Cloud Build (requires $ and will build if any Dockerfile present, so in different repo for now to avoid auto-triggering while we test). While all are configured, to avoid collisions, only one will do the actual pushing of coverage reports to Codacy and releases to BinTray. This is controlled via env var flags. In the future, we will pick one and optimize (including likely upgrading machine class for faster builders), but for now the goal is just to get the automated flow working with the new images, and we can have real world comparison to discuss. Since we are making major changes to our general develop/branching/release process, the goal is to get this integrated with the release flag *disabled*, and do manual releases using the new scripts for a bit. However, all the CI environments should be triggered in the background, and will do everything up to but excluding the final push to BinTray, giving us the flexibility to see how it is operating on real world data, so we can debug and tune before making it the default, and getting us familiar with the new branch model. Docs related to the current manual release process are in draft here: https://github.com/openlawteam/openlaw-core/pull/123