Unified worflow to build TEST BETA and LIVE artifacts #4250
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- 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
- 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
- remove CI_BUILD - convert DCI_TAG from ENV to CMake variable
…rkflow matrix usage
- 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)
- Remove old workflows - Create 1 workflow for all environments (Network Matrix) - Keep current build logic (build scripts still differ per OS)
- 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
Convert nanocurrency/nano-env image to self built ghcr.io/${{ github.repository }} image
- convert ref to CI_TAG - use CI_TAG in aws deploys
gr0vity-dev
force-pushed
the
wip/unified_artifacts_worflow
branch
from
7ea2a1b
to
174df34
Compare
- add possibility to specify registry - use ghcr.io instead of variable for ghcr_image_name
- vars.S3_BUCKET_NAME - vars.S3_BUILD_DIRECTORY - vars.DOCKER_REGISTRY - vars.DOCKER_USER
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.
…txt in the tag used to build the node
- use the new prepare scripts (Linux, MacOS & Windows) - remove the need the dependency on nano-env:gcc
- Build the nano-env docker image in the current workflow - Use the locally built image.
- Remove duplicate BUILD_TYPE - move SANITIZER to ci/build-node.sh ARGs
- fixes a bug when we have 2 similar branches with tags (e.g. some-branch and some-branch-2)
Prevent modification of global git settings on a developer machine
- 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
- make sure V{Major}.0 is created even if the user forgets to set increment to 0
- by redefining local output=$1 it is set to 0 instead of "" and a file called 0 was created
- increment is 1 by default - if increment is 0, an existing tag will be updated (origin push -f).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a draft that builds on our current infrastructure and removes the need for multiple build scripts
Improvements :
Behaviour changes
Todos:
Executiung the workflow on a release branch should have a slightly different behaviour.
--> This could be solves by autodetecting if a build already exists.
--> It could also be solved by an input_parameter (increment_version)
--> increment_version would increment
pre_releasefor any branch except "releases/" branches--> increment_version would increment
minor_versionin case the workflow operates on "releases/" branch--> increment_version could be an integer (0,1,2,-1,...) by which the version is incremented
--> increment_version could be an boolean (0,1) to enabled or disable incrementing the version
Our current workflow fails when no new changes have been committed. This prevents a new tag generation.However it would be a better approach to make it pass with a message that no tag was created, so CI remains green.
Currently the workflow uses the develop branch to get the MajorVersion number and subtracts 1 in case of a release branch. However this seems fragile. A better approach would be to use the version from the branch the workflow runs on .The pre_release version is calculated during CI and not comitted. This means that even though a Tag is created, building this Tag manually will not result in the same pre_release version as the CI build. Evaluate if we want manual builds from a Tag to have the correct pre_release version.Create a "promotion" workflow that takes a reference, creates a release branch, sets the correct versions (for develop and release) and rebuilds the reference with the new release version numbers.(done in a separate PR)