[jitsi-dev] [jitsi-videobridge] jitsi-videobridge builds are not reproducible (#103)


#1

### Steps to reproduce

$ git clone -b 574 https://github.com/jitsi/jitsi-videobridge.git
$ mvn dependency:go-offline
$ ant -lib ~/.m2/repository/org/apache/maven/maven-ant-tasks/2.1.3 compile

### Expected results

Compile cleanly

### Actual results

compile:
    [mkdir] Created dir: /Users/dlee/prj/jitsi-videobridge/classes
    [javac] /Users/dlee/prj/jitsi-videobridge/build.xml:104: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
    [javac] Compiling 85 source files to /Users/dlee/prj/jitsi-videobridge/classes
    [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.7
    [javac] /Users/dlee/prj/jitsi-videobridge/src/main/java/org/jitsi/videobridge/transform/RetransmissionRequester.java:234: error: incompatible types: boolean cannot be converted to TransformEngine
    [javac]                         mediaStream.injectPacket(pkt, false, true);
...

### Notes

Even though `jitsi-videobridge` has a `pom.xml` file declaring its dependencies, very few of them are pinned to a specific version number. Even worse, many of the `org.jitsi` dependencies are on `SNAPSHOT` versions.

When these dependencies make breaking API changes, (such as [here](https://github.com/jitsi/jitsi-videobridge/commit/1be6e073e117a353687585fb548ec7c7741a4db4) and [here](https://github.com/jitsi/jitsi-videobridge/commit/4e62c12b808b5749f32abbb977c9f9c18c67b05d) for some recent examples), older versions of `jitsi-videobridge` will no longer compile. This make it especially difficult to pin to specific versions; especially since the downloads site only maintains the most recent 10 (or so) builds.

Versions should be specified in the `pom.xml` file, and set to non-`SNAPSHOT` versions where possible.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/103


#2

we've run into this as well...since building/running it re-pulls down the dependencies, sometimes just restarting the bridge can result in a breakage and require updating the branch, which is a bit annoying if we're trying to reproduce something.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/103#issuecomment-161392849


#3

@brianh5, if you're trying to reproduce something, you can go offline with Maven (leedm777 said above) in order to make sure that you stay with the same binaries.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/103#issuecomment-161419161


#4

@lyubomir `mvn dependency:go-offline` alone is insufficient. Often when you `ant compile`, it will check for updates to SNAPSHOT dependencies. (See the `updatePolicy` on [snapshots](https://maven.apache.org/ref/3.3.9/maven-settings/settings.html#snapshots)).
It's also common to have different artifacts in your local `~/.m2` repository across different build machines, which really throws a wrench in reproducibility.

The `go-offline` plugin just downloads all the dependencies needed to build/compile. It is only there b/c the older maven in the ant-maven-tasks chokes when you try to let it download the dependencies.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/103#issuecomment-161422782


#5

@leedm777, the Maven support in Videobridge has superseded the Ant support and the latter is there for the sole purpose of generating Debian packages. If you're trying to reproduce an issue, you may use a binary build (that you've downloaded or generated yourself) multiple times (i.e. distribute the binary build to multiple machines). Anyway, I don't personally plan on working on pinning versions into our .pom files (because that would put more effort on the active developers).

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/103#issuecomment-161426198


#6

@lyubomir is there any way to start up the bridge without it re-downloading and potentially breaking the build? what do you guys do in production? we've had issues where we've had to restart our videobridge and it breaks because a dependency is re-downloaded which breaks the build. what's the recommended way to lock all the versions for a deployed build? does the built debian package address that?

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/103#issuecomment-161430495


#7

@brianh5, production runs thoroughly tested builds (binary distributables such as Debian packages), only developers may run from source. The recommended way to deploy Videobridge is from a binary build. We provide Debian builds, you can use Ant to produce a Debian build yourself, or mvn package -Dassembly.skipAssembly=false to produce a .zip binary distributable.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/103#issuecomment-161431736


#8

@lyubomir thanks, that makes sense. i will still say, though, that this situation does make development (when building from source) a bit annoying.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/103#issuecomment-161437509


#9

@lyubomir In my experience, there's more work in dealing with build inconsistency across machines (or across time, in this case) than there is in keeping version numbers in the `pom.xml` file updated.

Martin Fowler has a [great writeup](http://martinfowler.com/bliki/ReproducibleBuild.html) on why reproducible builds are a Good Thing™.

In my case, we are running a particular version of jitsi-videobridge in production. We are having some problems with it, so I'd like to try out some patches to it to see if I can diagnose, or even fix, the problem. But because the builds aren't reproducible, I'm having a seriously difficult time even building the same version of code we're running in production.

Even if the old code could compile, changes in these external dependencies could cause different behavior in development, throwing a wrench in trying to troubleshoot problems.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/103#issuecomment-161437762


#10

Closed #103.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/103#event-543493296