Use dep to manage dependencies

[jhernand]

Currently the image inspector uses the trash tool to manage the
dependencies, using the vendor.conf file to declare them, and
commiting vendor directory to the source code repository.

This patch changes the project to use the dep tool and removes the
vendor directory from the source code repository. The dependencies
will be downloaded by the dep tool when running make.

[enoodle]

@jhernand what are the benefits of commiting the file Gopkg.lock ?
Seems like it is changed by dep ensure when the unconstrained dependencies are updated. It is similar to me to a Gemfile.lock.

[jhernand]

The advantage of having the Gopkg.lock file in the repository is that if you use dep ensure -vendor-only then it will get exactly the versions dependencies that you have listed in that file. Note that in the Makefile we are using that -vendor-only option, so the unconstrained dependencies will not be updated. Only if you run dep ensure manually will they be updated.

[enoodle]

I am very much for this,
When we moved to trash there was no clear standard but dep seems to be it now.
Also, not including vendor directory is a nice move in my opinion. It will be lighter repository and clearer for PRs that are adding/changing dependencies.

[simon3z]

@jhernand have you checked #68? At that time dep was not able to properly identify the dependencies resulting in bloated libraries inclusion. Have you checked that when moving to #85 we won't have dependency issues? (e.g. what's the result with trash vs dep?)

[jhernand]

My understanding from #68 and from how dep works is that it downloads more dependencies because it doesn't ignore tests. That means that after this patch there will be still much more files in the the vendor directory when using dep than when using trash. But note that the patch also changes the project so that the vendor directory will not be committed into the git repository, so it drastically reduces the set of files of the project (not of the repository itself, as old vendor contents will still be in the history).

As for #85, I think it will actually improve it a lot; the commit will go from 912 changed files to less than 20, which is good for review, for example.

[enoodle]

We can also change the way that we build the container image to not copy the whole project and build it on the image, but create the binary file locally and only copy that.
It will create smaller images as they won't need the golang compilers installed and will ignore the added files that dep is coping. This is the way that Prometheus is building the container image.

[jhernand]

Indeed, actually I wanted to do exactly that, and this was the first step.

[enoodle]

@jhernand I think I learned of this option from you and from @zgalor

[zgalor]

👍 for dep.
Regarding building the binary outside of the Dockerfile, This will probably break docker hub auto-build

[jhernand]

To overcome the problem with the docker hub auto-build we could maybe modify the Travis configuration so that it builds and pushes the image to docker hub.

[simon3z]

As for #85, I think it will actually improve it a lot; the commit will go from 912 changed files to less than 20, which is good for review, for example.

Nice! 👍
@jhernand do you want to queue this after #91 ?

[enoodle]

ping @jhernand Can you rebase this on the changes from #91 please?

[openshift-bot]

@jhernand: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.