* Use ninja build tool and compile blockchain-explorer Ninja builds TON much faster; * Use clang instead of gcc * remove blockchain-explorer since target not found on github action * move ccpcheck to other gitaction * run nativelib-java only against wallets branch for now * rename gitaction * Update windows2019x64-tonlib-java.yml * Update windows2019x64-tonlib-java.yml * Update macos-10.15-tonlib-java.yml * Update windows2019x64-tonlib-java.yml * Update windows2019x64-tonlib-java.yml |
||
---|---|---|
.github/workflows | ||
adnl | ||
blockchain-explorer | ||
catchain | ||
CMake | ||
common | ||
create-hardfork | ||
crypto | ||
dht | ||
dht-server | ||
doc | ||
docker | ||
example | ||
fec | ||
http | ||
keyring | ||
keys | ||
lite-client | ||
lite-client-docs | ||
memprof | ||
overlay | ||
rldp | ||
rldp-http-proxy | ||
rldp2 | ||
storage | ||
tdactor | ||
tddb | ||
tdfec | ||
tdnet | ||
tdtl | ||
tdutils | ||
terminal | ||
test | ||
third-party | ||
tl | ||
tl-utils | ||
ton | ||
tonlib | ||
utils | ||
validator | ||
validator-engine | ||
validator-engine-console | ||
validator-session | ||
.clang-format | ||
.clang_complete | ||
.gitattributes | ||
.gitignore | ||
.gitmodules | ||
Changelog.md | ||
CMakeLists.txt | ||
git.cc.in | ||
git.h | ||
git_watcher.cmake | ||
GPLv2 | ||
LGPLv2 | ||
LICENSE.LGPL | ||
README.md | ||
run-clang-format.sh |
TON
Main TON monorepo, which includes the code of the node/validator, lite-client, tonlib, FunC compiler, etc.
Updates flow:
-
master branch - mainnet is running on this stable branch.
Only emergency updates, urgent updates, or updates that do not affect the main codebase (GitHub workflows / docker images / documentation) are committed directly to this branch.
-
testnet branch - testnet is running on this branch. The branch contains a set of new updates. After testing, the testnet branch is merged into the master branch and then a new set of updates is added to testnet branch.
-
backlog - other branches that are candidates to getting into the testnet branch in the next iteration.
Usually, the response to your pull request will indicate which section it falls into.
"Soft" Pull Request rules
- Thou shall not merge your own PRs, at least one person should review the PR and merge it (4-eyes rule)
- Thou shall make sure that workflows are cleanly completed for your PR before considering merge
Workflows responsibility
If a CI workflow fails not because of your changes but workflow issues, try to fix it yourself or contact one of the persons listed below via Telegram messenger:
- C/C++ CI (ccpp-linux.yml): TBD
- C/C++ CI Win64 Compile (ccpp-win64.yml): TBD