-
Notifications
You must be signed in to change notification settings - Fork 490
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
Derive the swagger version from the go.mod file #1709
Derive the swagger version from the go.mod file #1709
Conversation
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 the telemetry changes intentional?
@@ -17,6 +17,7 @@ require ( | |||
github.com/gen2brain/beeep v0.0.0-20180718162406-4e430518395f | |||
github.com/getkin/kin-openapi v0.22.0 | |||
github.com/go-chi/chi v4.1.2+incompatible // indirect | |||
github.com/go-swagger/go-swagger v0.25.0 |
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.
Do we want this dependency in go.mod
since it is used by our build process but not depended on by our software?
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.
It's currently required by our makefile.. so I would lean toward "yes".
But that's not the only way to achieve that :
we could have another go.mod/go.sum in a separate directory, and fetch the go-swagger from there.
I think that it makes it simpler to know that all the dependencies are in one location, though.
ReportHistoryLevel logrus.Level `json:"-"` // text marshalers which breaks our backward compatibility. | ||
FilePath string // Path to file on disk, if any | ||
ChainID string `json:"-"` | ||
SessionGUID string `json:"-"` | ||
UserName string |
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 these telemetry config changes appropriate for this PR?
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.
The downside of having a single go.mod for both the go-swagger and our code is that we need to synchronize versions of shared components. These changes are backward compatible, so I could do these without applying this PR, and have the PR applied afterward. ( but I don't think it would add much more meaningful granularity.. )
If you think that these changes need to be splitted off, please let me know and I'll create a separate PR for these.
@tsachiherman The changes make sense, but I still don't understand why getting/installing swagger in Can you explain this a bit further please? |
Yes, of course. The I think that we need to address this as well, but that's already a separate issue. |
Ok, I see. Thanks for jumping on the ticket. |
As part of a refactoring effort in #1709, a small bug was introduced that changed the intended behavior of `loadTelemetryConfig`. This PR restores the previous behavior and adds a unit test for that.
Derive the swagger version from the go.mod file
) As part of a refactoring effort in algorand#1709, a small bug was introduced that changed the intended behavior of `loadTelemetryConfig`. This PR restores the previous behavior and adds a unit test for that.
) As part of a refactoring effort in algorand#1709, a small bug was introduced that changed the intended behavior of `loadTelemetryConfig`. This PR restores the previous behavior and adds a unit test for that.
Summary
We have the swagger version hard coded in the
configure_dev-deps.sh
file, whereas all the other go modules have their version stored in thego.mod
file.This change takes the module version from the
go.mod
file for the swagger as well.This is a followup on #1704
Test Plan
Since tip-of-tree on the swagger repo would break our build, a successful build ensures that the solution works as expected.