Update build metadata. don't trigger from pushed tags anymore

[CharlieC3]

• Updates the package name and version displayed in the /v2/info endpoint.

  • The server_version at /v2/info and stacks-node version command should now read something similar to:

  "stacks-node v24.3.2.0-xenon (build-metadata:0087561+, release build, linux [x86_64])"

  docker run --rm build-metadata-stretch stacks-node version
  stacks-node v24.3.2.0-xenon (build-metadata:0087561+, release build, linux [x86_64])

• Disables triggering a release when a tag is pushed up. cc @kantai
  • I disabled this because since we added a GH workflow which creates a new clarity-js-sdk PR upon each stacks-blockchain release, a new tag that gets created by the standard release workflow will create a loop, causing the release workflow to run again and attempt re-releasing the version.
  • With this disabled, we will no longer be able to push up a Git tag created locally to trigger a new release. This GH workflow will need to be invoked manually, with a new tag passed into the textbox.
  • @kantai if you want this to remain enabled, an alternative solution is possible but will require more testing to ensure it doesn't break the clarity-js-sdk-pr workflow.

Closes #2275
Closes https://github.com/blockstackpbc/devops/issues/554

Type of Change

• New feature
• Bug fix
• API reference/documentation update
• Other

Does this introduce a breaking change?

No

Are documentation updates required?

No

Testing information

1. Run a new node via docker run -p 20443:20443 --rm blockstack/stacks-blockchain:build-metadata-stretch
2. Open localhost:20443/v2/info in a browser once to initial boot finishes.

Checklist

• Code is commented where needed
• Unit test coverage for new or modified code paths
• npm run test passes
• Changelog is updated
• Tag 1 of @person1 or @Person2

[kantai]

Disables triggering a release when a tag is pushed up. cc @kantai

This works for me

[CharlieC3]

@kantai Did you see this part?

I tested this change out locally and it doesn't seem to do what we want it to do. The server_version in the /v2/info endpoint still reads blockstack-core 0.0.1 => 23.0.0.0. @kantai Can you double check this?

I'm wondering if the version and package name cannot be overridden by ENV vars because it's defined in the Cargo.toml.

[diwakergupta]

@kantai Did you see this part?

I tested this change out locally and it doesn't seem to do what we want it to do. The server_version in the /v2/info endpoint still reads blockstack-core 0.0.1 => 23.0.0.0. @kantai Can you double check this?

I'm wondering if the version and package name cannot be overridden by ENV vars because it's defined in the Cargo.toml.

@CharlieC3 that's because code relies on option_env!, which inspects an environment variable at compile time, not run time: https://doc.rust-lang.org/std/macro.option_env.html

The blockstack-core and 0.0.1 are coming from the main Cargo.toml. I'm less sure about the 23.0.0.0, but either way, if you set these variables when building locally, it should work.

[CharlieC3]

@diwakergupta The env vars are getting set before the build occurs.

I also tried setting the env vars during runtime in the docker container just to test, but it doesn't seem to have any affect (as expected from the reasons you mentioned).

[CharlieC3]

Not sure if there's a better way to convert a Option<&'static str> to Option<String>.

[kantai]

That's a perfect approach.

[blockstack-devops]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.