Describe the bug
Is there a way to set the swagger version at build time?
Currently , our repos leverage swag init to generate swagger docs. Currently the top level swagger versioning is defined through annotations like this:
// @title Service API Definition
// @version 1.12.4
// @description ...
// @BasePath /service/v1
func main() {}
This yields v1.12.4 in the swagger docs, as expected. The service uses embed to serve the swagger page.
However, is there a way to have define this 1.12.4 version dynamically? We would like to start using semantic-release, and are wondering how we can have github actions trigger a version increment without having to re-run swag init and rebuild the go service.
I am curious how other folks use swag init and dynamic versioning -- perhaps I am approaching this incorrectly. I appreciate any input -- thanks!
Describe the bug Is there a way to set the swagger version at build time?
Currently , our repos leverage
swag init
to generate swagger docs. Currently the top level swagger versioning is defined through annotations like this:This yields v1.12.4 in the swagger docs, as expected. The service uses
embed
to serve the swagger page.However, is there a way to have define this
1.12.4
version dynamically? We would like to start using semantic-release, and are wondering how we can have github actions trigger a version increment without having to re-runswag init
and rebuild the go service.I am curious how other folks use
swag init
and dynamic versioning -- perhaps I am approaching this incorrectly. I appreciate any input -- thanks!Your swag version 1.16.3
Your go version go1.22.3 darwin/arm64