#33953: Provide a way for easily updating Go dependencies of projects --------------------------------------+-------------------------- Reporter: gk | Owner: tbb-team Type: enhancement | Status: new Priority: Medium | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: tbb-rbm | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: --------------------------------------+--------------------------
Comment (by boklm): Replying to [comment:2 cohosh]: > > 1) Use go mod vendor to vendor in the dependencies and then build with -mod=vendor to use the vendor folder with the dependencies. > > How would this work? Would we have to pull from a separate snowflake branch that has this vendor folder checked in? If we're going to pull all the dependencies at once, I'd rather do something like option (3), since it sounds like there's already a workflow present for something similar. Maintaining the vendor directory sounds tricky. I think this can be done by adding a `go_mod_vendor` step, which will use a container with network enabled and a snowflake source tarball (from the same git clone) to run `go mod vendor` and generate a tarball which will be used as `input_files` for the snowflake build. I have not tested it, and it probably does not work yet, but I think this could look like this: https://gitweb.torproject.org/user/boklm/tor-browser- build.git/commit/?h=bug_33953_go_mod_vendor&id=5e7c5b88bc22548262744f7ec435210ebfaed221 With this we will be running "go mod vendor" and creating a `snowflake-go- mod-tarball-$git_hash.tar.xz` tarball each time the snowflake commit changes. However the tarball will probably not change for each commit, so as an alternative we could name it `snowflake-go-mod- tarball-$expected_sha256sum.tar.xz` (where $expected_sha256sum is the expected checksum of the tarball, assuming building it is reproducible) to avoid regenerating it when it is not expected to change. > > > I think it's worth attempting to exclude go module dependencies that are not needed. > > My thought now is that if we go with options (1) or (3) this might not matter so much. Since the dependencies aren't used to build the binary, it's not like they are contributing to binary size. It was more a pain point from a maintenance and rbm project blowup perspective. It added to the size of the rbm repository and increased build time. But if we're doing (1) or (3) these aren't a concern anymore if I am understanding correctly. Yes, I think unneeded dependencies isn't a big concern if we're doing (1) or (3). -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33953#comment:3> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs