Skip to content

Reintroduce RC builds for releases branches#4381

Merged
pwojcikdev merged 5 commits intonanocurrency:developfrom
gr0vity-dev:prs/refactor_tag_generation
Mar 15, 2024
Merged

Reintroduce RC builds for releases branches#4381
pwojcikdev merged 5 commits intonanocurrency:developfrom
gr0vity-dev:prs/refactor_tag_generation

Conversation

@gr0vity-dev
Copy link
Copy Markdown
Contributor

@gr0vity-dev gr0vity-dev commented Jan 21, 2024

This PR improves the next_tag_generation that was introduced in #PR4256 and replaces what we had before

Screenshot 2024-01-20 at 10 44 04

Here are a few examples of what tag is generated when running the workflow :

develop branch (uses 'DB' as suffix)

|---------|--------------|------------------|-------------------------------------|
| attempt |  branch_name | is_release_build |  result                             |
|---------|--------------|------------------|-------------------------------------|
|       1 |   develop    |  ignored         |  create tag V27.0DB1                | (no V27.0DB* tag exists, so it's created)
|---------|--------------|------------------|-------------------------------------|
|       2 |   develop    |  ignored         |  no new commit --> exit 0           |
|---------|--------------|------------------|-------------------------------------|
|       3 |   develop    |  ignored         |  new commit --> create tag V27.0DB2 |
|---------|--------------|------------------|-------------------------------------|

releases/v branch (uses 'RC' as suffix)

-if IS_RELEASE_BUILD is set to true during workflow execution, the suffix is ignored

|---------|----------------|------------------|----------------------------------------|
| attempt |  branch_name   | is_release_build |  result                                |
|---------|----------------|------------------|----------------------------------------|
|       1 |   releases/v26 |  false (default) |  create tag V26.0RC1                   | (no V26.0RC* tag exists, so it's created)
|---------|----------------|------------------|----------------------------------------|
|       2 |   releases/v26 |  false           |  no new commit --> exit 0              |
|---------|----------------|------------------|----------------------------------------|
|       3 |   releases/v26 |  false           |  new commit --> create tag V26.0RC2    |
|---------|----------------|------------------|----------------------------------------|
|       4 |   releases/v26 |  true            |  create tag V26.0                      |
|---------|----------------|------------------|----------------------------------------|
|       5 |   releases/v26 |  true            |  no new commit --> exit 0              |
|---------|----------------|------------------|----------------------------------------|
|       6 |   releases/v26 |  false           |  no new commit --> create tag V26.1RC1 | (no V26.1RC* tag exists, so it's created)
|---------|----------------|------------------|----------------------------------------|
|       7 |   releases/v26 |  false           |  no new commit --> exit 0              |
|---------|----------------|------------------|----------------------------------------|
|       8 |   releases/v26 |  true            |  no new commit --> exit 0              |
|---------|----------------|------------------|----------------------------------------|
|       9 |   releases/v26 |  false           |  new commit --> create tag V26.1RC2    |
|---------|----------------|------------------|----------------------------------------|
|      10 |   releases/v26 |  true            |  new commit --> create tag V26.1       | (commit `set(CPACK_PACKAGE_VERSION_MINOR "1")` to releases/v26)
|---------|----------------|------------------|----------------------------------------|

When looking at attempt 6, the minor_version is set to 1 because a V26.0 release build exists (created in attempt 4).

Any other branch uses the branch_name as suffix

|---------|------------------|------------------|----------------------------------------------------|
| attempt |  branch_name     | is_release_build |  result                                            |
|---------|------------------|------------------|----------------------------------------------------|
|       1 |   prs/good_stuff |  ignored         |  create tag V{Maj}.0prs_good_stuff1                |
|---------|------------------|------------------|----------------------------------------------------|
|       2 |   prs/good_stuff |  ignored         |  no new commit --> exit 0                          |
|---------|------------------|------------------|----------------------------------------------------|
|       3 |   prs/good_stuff |  ignored         |  new commit --> create tag V{Maj}.0prs_good_stuff2 |
|---------|------------------|------------------|----------------------------------------------------|

homebot added 2 commits January 21, 2024 10:27
Extend tag generation functionality
cb2c161 
- Add `IS_RELEASE_BUILD` env variable to indicate release builds
- Set default suffix to RC for releases/v branches
- Set default suffix to DB for develop branch
- Set default suffix to `branch_name` for all other branches
- Add -s flag for manual suffix
- Make sure tags have the right min_version and pre_release_version in their CMakeLists.txt
- Make sure RC builds have the right min_version
- Write variables to GITHUB_ENV if run from workflow
- improve variable names
Reintroduce RC builds
5df25c7 
- `is_release_build` is ignored except if the workflow executes on a `releases/v` branch
- `is_release_build` is false by default and creates RC builds that increment when a new commit is detected
- simplify workflow by using environment variables
@gr0vity-dev gr0vity-dev marked this pull request as ready for review January 24, 2024 10:16
pwojcikdev
pwojcikdev previously approved these changes Mar 14, 2024
View reviewed changes
Copy link
Copy Markdown
Contributor

@pwojcikdev pwojcikdev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on flowchart this makes a lot of sense, but I haven't gone through the bash scripts in much detail. We can always fix problems later.

Would it be a good idea to rename .github/workflows/artifacts_build_deploy.yml to simply .github/workflows/build_deploy.yml so it's shorter and matches actual workflow name?

@pwojcikdev pwojcikdev merged commit 77a3512 into nanocurrency:develop Mar 15, 2024
@qwahzi qwahzi mentioned this pull request Mar 15, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@pwojcikdev pwojcikdev pwojcikdev left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@gr0vity-dev @pwojcikdev