No description
47568010c0* Prepare CMakeLists.txt for unified builds
- Remove CI_BUILD Cmake variable.
- Convert CI_TAG from ENV variable to CMake variable
- CI_VERSION_PRE_RELEASE can be set in non CI builds
* Prepare build.sh and node Dockerfile for unified builds
- add CI_TAG and CI_VERSION_PRE_RELEASE to build.sh
- add useful ARG with default values to Dockerfile so they can be passed to the build.sh script
* Prepare WIndows for unified builds
- remove CI_BUILD
- convert DCI_TAG from ENV to CMake variable
* Convert TEST BETA and LIVE variable to NETWORK variable for easier workflow matrix usage
* Make docker builds and deploys more modular
- Remove dependency on the workflow name
- COnvert $GITHUB_WORKFLOW to $NETWORK
- Create smaller functions with limited scope
- Create similar deploy functions for docker and github container registries (hub.docker and ghcr)
* Create unified workflow to build TEST BETA and LIVE artifacts
- Remove old workflows
- Create 1 workflow for all environments (Network Matrix)
- Keep current build logic (build scripts still differ per OS)
* Remove hardcoded repo from build and deploy scripts
- skip hub.docker deploys if DOCKER_PASSWORD is not provided
- Create DOCKER_HUB variable which defaults to nanocurrency (backwards compatible)
- Create DOCKER_USER variable which defaults to nanoreleaseteam (backwards compatible)
- create S3_BUCKET_NAME variable that defaults to repo.nano.org if not provided (backwards compatible)
- only use S3_BUILD_DIRECTORY if provided
* Make workflow repository agnostic
Convert nanocurrency/nano-env image to self built ghcr.io/${{ github.repository }} image
* Fix CI_TAG usage
- convert ref to CI_TAG
- use CI_TAG in aws deploys
* Use same login for ghcr and hub.docker
* Fix docker login
- add possibility to specify registry
- use ghcr.io instead of variable for ghcr_image_name
* Fix nano network during build
* Use config variables instead of secrets for non secret variables
- vars.S3_BUCKET_NAME
- vars.S3_BUILD_DIRECTORY
- vars.DOCKER_REGISTRY
- vars.DOCKER_USER
* Fix: Make build process repository agnostic by specifying vars.DOCKER_REGISTRY
* Make tag generation branch agnostic
The goal is to simplify tag generation process and commit the version_pre_release into CMakeLists.txt for each tag.
If a user checks out a specific tag and builds it, the version_pre_release is set correctly.
- remove workflow_dispatch inputs. It operates on the selected branch.
- The cronjob is executed on develop branch only.
- replace ci/actions/dev-build-tag-gen.sh with ci/actions/generate_next_git_tag.sh
- generate_next_git_tag.sh is branch agnostic and operates on ${{ github.ref }}
- generate_next_git_tag.sh succeeds even if no new tag is generated
- the workflow only executes the build jobs if a new tag was created (if: ${{ needs.prepare_build.outputs.TAG_CREATED == 'true' }})
- generate_next_git_tag.sh uses V${current_version_major}.${current_version_minor}${branch_name} for tags.
- for "develop" branch_name is converted to DB --> (e.g V26.0DB1)
- generate_next_git_tag.sh uses a -c flag that is responsible to update CMakeLists.txt with correct version_pre_release, create and push the tag to origin.
* Remove CI_VERSION_PRE_RELEASE as it has been committed to CMakeLists.txt in the tag used to build the node
* Use the new prepare scripts
- use the new prepare scripts (Linux, MacOS & Windows)
- remove the need the dependency on nano-env:gcc
* Make usage of nano-env:rhel explicit
- Build the nano-env docker image in the current workflow
- Use the locally built image.
* Fix typo in default BUILD_TYPE
- Remove duplicate BUILD_TYPE
- move SANITIZER to ci/build-node.sh ARGs
* Make sure the existing_tags ending is numeric
- fixes a bug when we have 2 similar branches with tags (e.g. some-branch and some-branch-2)
* Remove --global for git config
Prevent modification of global git settings on a developer machine
* Handling release branches differently.
- refactored script by making it more modular
- script expects releases to be made from a branch called `releases/v{Major}`
- add -i flag to indicate wether or not to increment the generated tag
- -i increments version_minor for release branches: tag --> V{Major}.{Minor + increment}
- -i increments version_pre_release for all other non-release branches: tag --> V{Major}.{Minor}{branch_name}{pre_release + increment}
- -o outputs either `version_pre_release` or `version_minor` depending on the branch
Prevent incrementing if no tag exists yet
- make sure V{Major}.0 is created even if the user forgets to set increment to 0
Make tag_created=true explicit
* Prevent output file from being created when -o is not provided
- by redefining local output=$1 it is set to 0 instead of "" and a file called 0 was created
* prevent script exit from grep returning a non-zero exit status if it doesn't find anything
* Add increment input to the workflow and force push if tag is unchanged
- increment is 1 by default
- if increment is 0, an existing tag will be updated (origin push -f).
fixup! Add increment input to the workflow
* Allow tag creation without file changes
- the first tag of a releases/ branch creates no changes
- a tag run with increment=0 creates no changes
in both cases we want to create the tag (again)
* feat: implement workflow to prepare for a new major software release
- Checks out the repository based on github.ref.
- Extracts and sets current major and minor versions from CMakeLists.txt of github.ref.
- Fetches the default branch name and sets it as an output.
- Checks for existence of a corresponding release branch. If present, the workflow aborts, if not, it continues and sets the new release branch name.
- Increments the major version in CMakeLists.txt on the default branch, commits this change, and pushes it back.
- Checks out a new release branch, sets the pre-release version to 0 in CMakeLists.txt, commits this change, and pushes the new branch to the repository.
fix: Configure git and fix output variables
Change the order of steps to make the flow more natural
Fix curl DEFAULT_BRANCH
fix
fix
* Rename workflow to something more meaningful
* Remove increment input from workflow
- Autodetect if we need to increment the version or not on the release branch
Expected behaviour :
- Running the workflow multiple times without a new commit will rebuild and republish the same artifacts
- Running the workflow after a new commit was made to the releases branch will increment version_minor by 1
- the version_minor is updated in CMakeLists.txt and committed to the release branch
- a new tag is created and pushed with the incremented version_minor
- Make logic for both release and other branches more obvious
--> TODO?: instead of force pushing, we could remove -f option if branch or tag already exist
* Retry "brew update" up to 5 times with 15s interval
* Apply suggestions from PR review (1/2)
* Apply suggestions from PR review (2/2)
Convert if/else into case..in
---------
Co-authored-by: gr0vity-dev <gr0vity-dev@users.noreply.github.com>
|
||
|---|---|---|
| .github | ||
| api/flatbuffers | ||
| ci | ||
| CL | ||
| cmake | ||
| coverage | ||
| crypto | ||
| debian-control | ||
| doc/diagram | ||
| docker | ||
| doxygen | ||
| etc | ||
| images | ||
| nano | ||
| submodules | ||
| systest | ||
| util | ||
| valgrind | ||
| .clang-format | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| asan_blacklist | ||
| boost_checkout_lite.sh | ||
| CMakeLists.txt | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| doxygen.config | ||
| Info.plist.in | ||
| LICENSE | ||
| logo.png | ||
| Nano.icns | ||
| Nano.ico | ||
| Nano.rc | ||
| nanocurrency-beta.spec.in | ||
| nanocurrency.spec.in | ||
| qt.conf | ||
| README.md | ||
| rep_weights_beta.bin | ||
| rep_weights_live.bin | ||
| resources.qrc | ||
| SECURITY.md | ||
| tsan_clang_blacklist | ||
| tsan_suppressions | ||
| valgrind.supp | ||
What is Nano?
Nano is a digital payment protocol designed to be accessible and lightweight, with a focus on removing inefficiencies present in other cryptocurrencies. With ultrafast transactions and zero fees on a secure, green and decentralized network, this makes Nano ideal for everyday transactions.
Guides & Documentation
Other documentation details can be found at https://docs.nano.org.
Links & Resources
Want to Contribute?
Please see the contributors guide.
Contact us
We want to hear about any trouble, success, delight, or pain you experience when using Nano. Let us know by filing an issue, joining us on Reddit, or joining us on Discord.