Closed snobbee closed 8 months ago
What exactly does goreleaser do and how does it benefit us? Our current official way of building is "make install". This should always produce the official sifnoded binary. We should only have one way of building, and it should run locally in exactly the same way as in GitHub actions.
We already have too many different ways to do the same thing, so before we introduce any new tool like this it's important to make sure we don't introduce even more ways, but streamline the process and clean up everything except "the single source of truth".
I understand the importance of maintaining a single, consistent build process. The intention behind proposing goreleaser
is not to introduce another method of building, but to enhance our current one. Here's why:
Cross-Platform Binaries: While "make install" works well, it may not be the most efficient way to produce binaries for all major platforms. goreleaser
excels in this regard, enabling us to easily generate binaries for multiple platforms without the complexity that might come with a Makefile alone.
Adoption in the Cosmos Ecosystem: Several projects within the Cosmos ecosystem have already adopted goreleaser
. For instance, both Osmosis and Cosmos SDK use it. This not only showcases its reliability but also hints at the potential benefits it offers, especially in terms of standardizing builds across the ecosystem.
Streamlined Release Process: Take a look at the Osmo release to see the output goreleaser
can produce. It not only builds the binaries but also structures them in a clean, organized manner, which can be extremely beneficial for our users and for ensuring clarity in our release process.
Integrating goreleaser
doesn't mean we're introducing a new build method. Instead, we're enhancing our existing one, ensuring that it remains the single source of truth, but is more efficient, consistent, and in line with what's becoming a standard in the Cosmos ecosystem.
@snobbee That's a great sales pitch, but it doesn't really answer the question of how it benefits us. For example, due to Peggy our build process has lot of dependencies and complications, including npm, docker, smart contracts, yarn, protobuf etc., They are highly complex and they break all the time, causing us a lot of grief. The real source of our pain is technical debt and goreleaser will most definitely not help us with that. The proper thing to do would be to focus on redesigning our build process from the ground up, in a way that covers all our needs holistically, succintly and comprehensively. It will take a lot of effort to pay off the debt, and until then, any partial solution will have a very limited benefits (if at all). I'm not opposing using goreleaser, my concern is that the longer we wait the higher the price we are paying.
LGTM
@snobbee That's a great sales pitch, but it doesn't really answer the question of how it benefits us. For example, due to Peggy our build process has lot of dependencies and complications, including npm, docker, smart contracts, yarn, protobuf etc., They are highly complex and they break all the time, causing us a lot of grief. The real source of our pain is technical debt and goreleaser will most definitely not help us with that. The proper thing to do would be to focus on redesigning our build process from the ground up, in a way that covers all our needs holistically, succintly and comprehensively. It will take a lot of effort to pay off the debt, and until then, any partial solution will have a very limited benefits (if at all). I'm not opposing using goreleaser, my concern is that the longer we wait the higher the price we are paying.
We don't even know if we're coming back to peggy so maybe let's postpone any efforts fixing the peggy build process. @jzvikart what do you think?
@pgoos Absolutely, if we're not going back to Peggy, dropping support for it would be a massive relief. But until we get a decision to permanently drop Peggy, we have to keep supporting it. Let's talk about this during the next meeting.
@snobbee If we're going to uses this, please also update make install
target so that it uses goreleaser and keeps builds consistent across different environments rather than just adding another target.
Merging #3423 (0406ed7) into master (0c63583) will increase coverage by
0.00%
. Report is 5 commits behind head on master. The diff coverage is30.55%
.
@@ Coverage Diff @@
## master #3423 +/- ##
=======================================
Coverage 43.35% 43.36%
=======================================
Files 166 166
Lines 15895 15904 +9
=======================================
+ Hits 6891 6896 +5
- Misses 8591 8595 +4
Partials 413 413
Files | Coverage Δ | |
---|---|---|
app/app.go | 90.20% <100.00%> (+0.10%) |
:arrow_up: |
cmd/sifnoded/cmd/ibc-diag.go | 15.74% <ø> (ø) |
|
x/dispensation/types/types.go | 100.00% <100.00%> (ø) |
|
x/ibctransfer/helpers/conversion_helper.go | 37.19% <ø> (ø) |
|
x/ibctransfer/keeper/msg_server.go | 86.95% <ø> (ø) |
|
x/ibctransfer/types/mocks/expected_keepers_gen.go | 25.33% <ø> (ø) |
|
app/setup_handlers.go | 10.52% <0.00%> (+1.83%) |
:arrow_up: |
x/ibctransfer/onrecv_packet.go | 0.00% <0.00%> (ø) |
|
x/tokenregistry/types/mock/keeper_gen.go | 0.00% <0.00%> (ø) |
Integrate goreleaser to improve release process.