adapt_js / Exports

CI Build

mufl-poc

This is a proof-of-concept C++ implementation of the MUFL compiler. MUFL is a special purpose programming language loosely belonging to the functional language family. It is designed for programming with high degree of security guarantees.

Requirements and motivation:

  • No access to external data or components of any kind. ADAPT software is responsible for all communication with the outside world.
  • No access to system features or input/output
  • No access to memory, pointers, or low-level OS and hardware primitives
  • High degree of modularity with guaranteed protection of modules from each other
  • Transactional semantics: all code is run as atomic blocks called Transactions. Transactions are the only side-effects allowed in the software.
  • A data model to ensure consistency across platforms/environments and to ensure simplicity of implementation
  • Use of capability-based approach for security and permissioning (called in adapt Safe References)
  • Automated garbage collection, programmer does not decide what data to persist and what data to not persist, all accessible data is automatically saved, all inaccessible data is automatically discarded.

Development

First of all you need at least 15Gb of free space, 2CPU and 4GB RAM for building.

The easiest way is using our prepared docker-compose:

docker-compose up build-gpp-native
docker-compose up build-gpp-nitro
docker-compose up build-clang-native
docker-compose up build-emcc-wasm
docker-compose up build-gpp-native-debug
docker-compose up build-gpp-nitro-debug
docker-compose up build-clang-native-debug
docker-compose up build-emcc-wasm-debug

You can find more instructions below.

How to compile this project without docker.

Tests

./test.sh --unit-tests [debug|release] # UNIT
./test.sh [no argument] [debug|release] # REPL
./test.sh -r tests/Wiki [debug|release] # WIKI
./test.sh --node [debug|release] # NODEJS
./test.sh --wasm [debug|release] # BROWSER|NODEJS

Our Dev Flow

We use principles very similar to classic Trunk based development:

  • The main branch is our main development branch which serves as an integration branch for features. This branch will contain the complete history of the project. This branch should not be broken i.e. it should pass all builds and tests after each commit or merge.

  • Each new feature should reside in its own branch named by <task>/<short description> pattern. Feature branches use main as their parent branch. When a feature is complete, it gets merged back into main. You can merge changes from feature into main time to time, otherwise you should merge main into your feature branch before sending PR or merging it back into main in the end.

  • Once main has acquired enough features for a release (or a predetermined release date is approaching), you fork main into prerelease-{version} branch. Creating this branch starts the next release cycle, so no new features can be added after this point — only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it’s ready to ship, the prerelease branch gets forked into release-{version} and tagged with a version number. In addition, it should be merged back into main, which may have progressed since the prerelease was initiated.

  • hotfix branches are used to quickly patch production releases. Hotfix branches are a lot like prerelease branches and feature branches except they’re based on release instead of main. This is the only branch that should fork directly off of release. As soon as the fix is complete, it should be merged into both main and release (or the current prerelease branch), and release should be tagged with an updated version number.

  • For integration with Jira you should use special commit notation: <task name like DEVOPS-1> #comment <text here> #time <time here like 1h 10m>

  • When you work on feature in parallel with other team members, always use git fetch && git rebase && git push instead of git push.

jira commit convention for github to jira integration:

<ignored text> <ISSUE_KEY> <ignored text> #<COMMAND> <optional COMMAND_ARGUMENTS>

DEVOPS-16 #comment disable broken nitro builds #time 10m

semver.org convention for releases naming:

Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards compatible manner, and
  • PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Docker and Docker-Compose builds

Build Dependencies Container

Read only login to our private docker registry

docker login -u adaptframework -p dckr_pat_MKTpUkqi-plbOG5X3HDvX62XcF0

This will take ~5 mins and ~10GB of disk space

export DOCKER_BUILDKIT=1
docker build -t adaptframework/build-dependencies -f docker/build-dependencies/Dockerfile .

Cleanup

docker rmi $(docker images -f dangling=true -q)
docker builder prune -a
Run builds and tests

One by one

docker-compose up build-gpp-native
docker-compose up build-gpp-nitro
docker-compose up build-clang-native
docker-compose up build-emcc-wasm
docker-compose up build-gpp-native-debug
docker-compose up build-gpp-nitro-debug
docker-compose up build-clang-native-debug
docker-compose up build-emcc-wasm-debug

In parallel

docker-compose up -d

Cleanup

docker-compose down
Local development with mounting current dir inside the container
docker run -v $(pwd):/root/mufl-poc-cpp -it --rm adaptframework/build-dependencies /bin/bash