[tor-bugs] #33953 [Applications/Tor Browser]: Provide a way for easily updating Go dependencies of projects

[Tor Bug Tracker & Wiki]

#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