Marked as a draft until the changes a properly tested.

Looks good to me. There also some references to Travis in nano-pow-server.

Thanks @thsfs and @dsiganos . The nano-pow-server is not actively used, so we can probably leave that cleanup for now (likely to be archived at some point anyway). I did notice we have a docs reference to the CI_BUILD=TRUE variable using environment variables TRAVIS_TAG here: https://docs.nano.org/integration-guides/build-options/#cmake-variables - will that need to be cleaned up when this change is made?

Thanks @thsfs and @dsiganos . The nano-pow-server is not actively used, so we can probably leave that cleanup for now (likely to be archived at some point anyway). I did notice we have a docs reference to the CI_BUILD=TRUE variable using environment variables TRAVIS_TAG here: https://docs.nano.org/integration-guides/build-options/#cmake-variables - will that need to be cleaned up when this change is made?

@zhyatt , yes, it will look for CI_TAG variable instead when this PR is approved. So it is required to update the variable name in the docs together with this.

This will be tested on V24.0DB1 release.

@thsfs This branch was tested for beta artifact deployment but the workflow failed to deploy Docker with an error related to the tag passed in for the container. See:
https://github.com/nanocurrency/nano-node/runs/6116766364?check_suite_focus=true#step:5:6999

After discussing this with @thsfs it was clear that the way I ran this (workflow from this branch, but target for building develop) caused this issue. To help provide more flexibility in testing going forward, we are looking into methods for preventing the more sensitive actions (Docker and S3 upload of artifacts) to be skipped in specific test scenarios so we can test across the different environments without worry for triggering unnecessary builds externally.

We currently run the GitHub Actions by setting Use workflow from to the develop branch and typically set the tag to build as a tag for that version (ex. V24.0DB1). To help allow testing of the workflow for all options (test, beta, live) while preventing unnecessary uploads of test only live builds to S3/Docker, I propose the following changes:

Code: In the /.github/workflows/live_artifacts.yml file if the branch the workflow is being run from does not begin with the pattern releases/v, then don't trigger the ci/actions/deploy.sh or ci/actions/linux/ghcr_push.sh scripts.

Release process: Running the live artifacts to actually produce release builds will now need to be done by selecting the releases/v* branch in the Use workflow from option.

If these changes are made, then tests can be done for live by selecting any non-release branch and we can verify the builds will be made but not published.

Thoughts @thsfs ?

We currently run the GitHub Actions by setting Use workflow from to the develop branch and typically set the tag to build as a tag for that version (ex. V24.0DB1). To help allow testing of the workflow for all options (test, beta, live) while preventing unnecessary uploads of test only live builds to S3/Docker, I propose the following changes:

Code: In the /.github/workflows/live_artifacts.yml file if the branch the workflow is being run from does not begin with the pattern releases/v, then don't trigger the ci/actions/deploy.sh or ci/actions/linux/ghcr_push.sh scripts.

Release process: Running the live artifacts to actually produce release builds will now need to be done by selecting the releases/v* branch in the Use workflow from option.

If these changes are made, then tests can be done for live by selecting any non-release branch and we can verify the builds will be made but not published.

Thoughts @thsfs ?

Agreed with the proposed changes.

We currently run the GitHub Actions by setting Use workflow from to the develop branch and typically set the tag to build as a tag for that version (ex. V24.0DB1). To help allow testing of the workflow for all options (test, beta, live) while preventing unnecessary uploads of test only live builds to S3/Docker, I propose the following changes:
Code: In the /.github/workflows/live_artifacts.yml file if the branch the workflow is being run from does not begin with the pattern releases/v, then don't trigger the ci/actions/deploy.sh or ci/actions/linux/ghcr_push.sh scripts.
Release process: Running the live artifacts to actually produce release builds will now need to be done by selecting the releases/v* branch in the Use workflow from option.
If these changes are made, then tests can be done for live by selecting any non-release branch and we can verify the builds will be made but not published.
Thoughts @thsfs ?

Agreed with the proposed changes.

The PR #3822 addressed the proposed changes in a different manner.

Tests passing. Notice they pass the build part (that is the expected):

• Beta: https://github.com/thsfs/nano-node/actions/runs/2571336916
• Test: https://github.com/thsfs/nano-node/actions/runs/2571338972
• Live: https://github.com/thsfs/nano-node/actions/runs/2571330536