Purge the root vendor directory

[timflannagan]

Update the repository layout and avoid commiting the root vendor directory into source. Update the root .gitignore and ignore the vendor directory. For any CI/CD (or utility-esq Makefile targets) avoid referencing the vendor equivalent through go run ... and instead use the go-get-tool from the operator-sdk/kubebuilder world) and pull down that dependency at runtime.

[timflannagan]

/cc @joelanford

[timflannagan]

I realize we need to also bump this repository to Go 1.17.

[timflannagan]

Interesting: "failed to get packages from new commit "HEAD" (5116b59): could not determine GOARCH and Go compiler".

[joelanford]

Are we able to use go-get-tool for go-bindata as well?

[timflannagan]

Surprisingly, this was a bit more complicated that I had anticipated due to how bloated the manifests target is right now, and exporting the PATH variable to point to this repositories' root ./bin directory before running go generate ... wasn't working, and that command was always searching for packages in the vendor directory, despite no GOFLAGS being set in my local environment.

It's possible I'm missing something obvious, but given the o-f/api recent changes that contain massive changelogs due to dependency bumps, maybe we can tackle this in a follow-up, and/or generalize the value we see in the tools.go file going forward throughout the OLM-controller repositories?

[timflannagan]

I'd like to resolve that go-apidiff before merging this to avoid putting this repository in a state where we break that action, and potentially evaluate purging the root tools.go file.

/hold

[timflannagan]

Ah, it looks like we don't have the workflow_dispatch event trigger enabled for this repository. Opened a quick PR (#214) for enabling that for the two workflow definitions.

[timflannagan]

/hold cancel

[fgiloux]

I have seen how annoying the vendor directory is during PR. That said there are good reasons for keeping a copy of the dependencies. A possible mitigation could be to have the vendor directory stored in a separate repository when a new release is cut. What do you think?

[timflannagan]

I think the value of the vendor directory has somewhat deteriorated as modules become more stable, and my preference would be to remove the vendor directory from upstream repositories, while maintaining the vendor directory in any downstream environments. That should serve as a nice balance where we can rely on dependencies being available for downstream builds, but help improve the upstream contributor/reviewer experience. Thoughts?

[fgiloux]

to remove the vendor directory from upstream repositories, while maintaining the vendor directory in any downstream

Yes that sounds good to me. My main concern was indeed when there is a need to patch a downstream release and the dependency version is nowhere to be found.

[dinhxuanvu]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dinhxuanvu, timflannagan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dinhxuanvu]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tylerslaton]

/lgtm