Skip to content

Conversation

ptiurin
Copy link
Contributor

@ptiurin ptiurin commented Oct 8, 2025

This workflow was using a hack that relied on an outdated action internal. It has since been refactored into a separate version bump action. This allows simplifying the workflow here while using a shared language-independent action.

Copy link

sonarqubecloud bot commented Oct 9, 2025

@ptiurin ptiurin marked this pull request as ready for review October 9, 2025 08:18
@ptiurin ptiurin requested a review from a team as a code owner October 9, 2025 08:18
run: |
# Bump version = <number> in version file
sed -i "s/SdkVersion string = .*/SdkVersion string = \"${{ steps.tag_generation.outputs.new_version }}\"/g" version/version.go
sed -i "s/SdkVersion string = .*/SdkVersion string = \"v${{ steps.version.outputs.new-tag }}\"/g" version/version.go
Copy link
Contributor

Choose a reason for hiding this comment

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

I see a lot of places where we do v${...}. Does this mean that the tag that we put in the release action does not have v at the beginning? For jdbc we set v3.6.2 in the job. In go when we what to release v3.6.2 do we trigger the job with 3.6.2?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't provide the tag manually, it's automatically inferred from the commits made since the last tag in this action. It returns the new version without the v prefix. This is fine for Python SDK and some others as they keep releases numeric only. However, Go has v prefix in its releases so I'm adding it afterwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants