Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 4 commits into from
Jan 7, 2021

Conversation

CharlieC3
Copy link
Member

@CharlieC3 CharlieC3 commented Jan 5, 2021

  • 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])

Screen Shot 2021-01-06 at 10 59 15 PM

  • 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

@CharlieC3 CharlieC3 requested a review from kantai January 5, 2021 22:37
@CharlieC3 CharlieC3 self-assigned this Jan 5, 2021
@kantai
Copy link
Contributor

kantai commented Jan 5, 2021

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

This works for me

@CharlieC3
Copy link
Member Author

@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
Copy link
Member

@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
Copy link
Member Author

@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).

}

} else {
return option_env!("GIT_COMMIT").map(String::from);
Copy link
Member Author

Choose a reason for hiding this comment

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

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

Copy link
Contributor

Choose a reason for hiding this comment

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

That's a perfect approach.

@CharlieC3 CharlieC3 marked this pull request as ready for review January 7, 2021 03:50
@CharlieC3 CharlieC3 requested a review from kantai January 7, 2021 03:51
@CharlieC3 CharlieC3 merged commit 00284ee into master Jan 7, 2021
@CharlieC3 CharlieC3 deleted the build-metadata branch January 7, 2021 18:40
@blockstack-devops
Copy link
Contributor

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.

@stacks-network stacks-network locked as resolved and limited conversation to collaborators Nov 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

server_version wrong in /v2/info endpoint
4 participants