build: remove rake

[gbbr]

This change removes Rake, but before merging we must ensure that the build chain pipeline for both major agent versions will continue to work.

Related: DataDog/dd-agent-omnibus#234 and DataDog/datadog-agent#1303

[LotharSee]

To get the full scope of the change and what it means for the dev, can we also update the README to reflect what are the commands to run now (for install deps, test, build, lint, etc...)

[gbbr]

Done! I've also bumped CI to go1.9.4 (as per the linked PR with the build chain update), further decreasing CI time to around 40 seconds.

[LotharSee]

We should still use glide as we pinned configuration is glide.lock/glide.yaml.

[gbbr]

What would be the reason to do that? Everything is committed into vendor already. Are you thinking that there is a possibility that someone commits the wrong version into vendor and then it will cause unexpected behaviour? Because if that's the case then I think we can live with that and we should generally catch that in a review.

You can notice yourself the glide install causes no change to the working tree. I think the general consensus is to commit the vendor folder with any potential updates so it doesn't make sense to waste time running it every time.

Let me know if I'm missing something.

[LotharSee]

vendor isn't committed (and you won't see it with a glide install as it is part of the .gitignore), which is the one of the main purpose of using a tool to pin and manage dependencies.
It also allows much simpler dep management, with clear/explicit pin to specific versions of the deps.

[gbbr]

vendor isn't committed

Is there any particular reason why we don't? I can only see positive aspects to doing so. We are already doing this on most (if not all) our projects.

[LotharSee]

It is a very common practice (and is most languages, package.json, setup.py, Gemfile, ...) to only commit dependency description / lock and not their code. It has plenty of benefits:

• keep the repo small, prevent non interesting diff when upgrading
• provide a way to manage your dependencies: add, remove, upgrade, lock, list, ...

Which projects are you referring to? I don't think we are committing vendors in any of them.

[LotharSee]

Now that I looked at the 2 other related PRs, I think we should still keep here and wrap the various build commands in a single command.
It helped us in the past to revamp internals without having to change all the build change (for instance: move the info package, the move to cmd package, whatever will be next, ...).
It is made clear by looking at the omnibus and A6 PR, where the code got more complex and more internal-specific.

While Rake was overkill for that, maybe we could use a simple Makefile?

[gbbr]

Now that I looked at the 2 other related PRs, I think we should still keep here and wrap the various build commands in a single command.
It helped us in the past to revamp internals without having to change all the build change (for instance: move the info package, the move to cmd package, whatever will be next, ...).
It is made clear by looking at the omnibus and A6 PR, where the code got more complex and more internal-specific.

Yes, that is a good point. I have also thought about this. It keeps things more under our control. I will look into an alternative, where we can keep control on our side without having to change omnibus all the time.

[gbbr]

I have closed the two PRs changing the build chain. I am going to experiment with alternatives, such as creating a Makefile or maybe using just go generate ./....

[gbbr]

@LotharSee as you've suggested:

• Added back glide install
• Created Makefile
• Updated README.md

PTAL

[LotharSee]

Looking great to me!

Let's just be sure we update the buildchains at the same time to not impact Agent releases.

[gbbr]

Thanks. Build chain PRs are ready. I will wait with this until GA is out to minimise any breakage risks and will merge it on Friday or Monday.

DataDog/dd-agent-omnibus#235
DataDog/datadog-agent#1319

[gbbr]

Merging since GA was pushed to Tuesday 27th Feb.