-
Notifications
You must be signed in to change notification settings - Fork 863
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
Reintroduce engine get client version v1 with commit in manifest #7548
Reintroduce engine get client version v1 with commit in manifest #7548
Conversation
…e caclulateVersion (hyperledger#7537)" This reverts commit a8bbcd5. Signed-off-by: Matilda Clerke <matilda.clerke@consensys.net>
Signed-off-by: Matilda Clerke <matilda.clerke@consensys.net>
Signed-off-by: Matilda Clerke <matilda.clerke@consensys.net>
Signed-off-by: Matilda Clerke <matilda.clerke@consensys.net>
Signed-off-by: Matilda Clerke <matilda.clerke@consensys.net>
…ommit-in-manifest Signed-off-by: Matilda-Clerke <matilda.clerke@consensys.net>
Signed-off-by: Matilda Clerke <matilda.clerke@consensys.net>
This reverts commit f855091 Signed-off-by: Matilda Clerke <matilda.clerke@consensys.net>
…Version back to original spec Signed-off-by: Matilda Clerke <matilda.clerke@consensys.net>
Signed-off-by: Matilda Clerke <matilda.clerke@consensys.net>
Note: CHANGELOG.md may need to be updated if this is merged after the next release |
@@ -22,7 +22,8 @@ jar { | |||
'Specification-Title': archiveBaseName, | |||
'Specification-Version': project.version, | |||
'Implementation-Title': archiveBaseName, | |||
'Implementation-Version': calculateVersion() | |||
'Implementation-Version': calculateVersion(), | |||
'Commit-Hash': getGitCommitDetails(40).hash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we doing this everywhere as a matter of consistency? It seems like we only currently need this in the :besu
artifact, but I don't see a reason not to be consistent across all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I updated all of the gradle sub-modules where we're setting Implementation-Version to also set a Commit-Hash for consistency. Currently, it's only used in the besu module
@@ -823,7 +823,7 @@ task distDocker { | |||
dockerPlatform = "--platform ${project.getProperty('docker-platform')}" | |||
println "Building for platform ${project.getProperty('docker-platform')}" | |||
} | |||
def gitDetails = getGitCommitDetails(7) | |||
def gitDetails = getGitCommitDetails() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
8 seems fine, but if we are going to generate commit sha metadata that is different from the build artifact name, we may as well use all 40 here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, nothing blocking (except pesky failing info regex tests)
Signed-off-by: garyschulte <garyschulte@gmail.com>
re-fixes #6471
for reference:
https://github.com/ethereum/execution-apis/blob/main/src/engine/identification.md
The story behind this PR is as follows: The initial implementation of engine_getClientVersionV1 relied on including the commit hash in the Implementation-Version, to then be parsed in the BesuInfo class. As such, gradle was updated to use 8 character commit hashes, and ensure the memoized output of calculateVersion always included a commit hash. This caused a mismatch in the docker develop github action, which supplied a version with a 7 character commit hash. At this point, we reverted the changes made to implement engine_getClientVersionV1 and began work on the content of this PR to reintroduce engine_getClientVersionV1 with a less disruptive method of obtaining the commit hash. As seen in this PR, the method used is to include a Commit-Hash attribute in the MANIFEST.mf file of all built submodule jars. BesuInfo then extracts the commit hash, and the version is left as it was in both gradle and java runtimes.