scripts: add Makefile

[soltysh]

I'm adding Makefile to simplify dev workflow and make it similar to other components under openshift org.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: soltysh
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: tomassedovic

If they are not already assigned, you can assign the PR to them by writing /assign @tomassedovic in a comment when ready.

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[wking]

I'm personally fine with a Makefile like this, but see previous decisions to not go in this direction here and here.

[soltysh]

@crawford @abhinavdahiya any chance for changing your mind? /cc @smarterclayton since I think this is reasonable approach applied from k8s through all of our operators.

[abhinavdahiya]

IMO

• make all/build is better than ./hack/build.sh
• make verify is not useful to everybody as most people are not changing tf files all the time.
• no targets in the Makefile actually help dev workflow.
  libvirt vs non-libvirt release vs non-release
  using install-config store somewhere to create a cluster
  testing new release images.

So I would like to see more examples of how moving to make helps/improves our dev workflow or even if people using installer are going to use one workflow that we define... ?

[soltysh]

* `make all/build` is better than `./hack/build.sh`

Yes, that's probably my main motivation for Makefile.

* `make verify`  is not useful to everybody as most people are not changing `tf` files all the time.

I don't see any reason to have multiple verify targets.

* no targets in the Makefile actually help dev workflow.
  `libvirt` vs `non-libvirt` `release` vs `non-release`
  using install-config store somewhere to create a cluster
  testing new release images.

This contradicts to what you've said in the first point. I don't see any reason not to expand Makefile with additional targets which will hide the script complexity.

[abhinavdahiya]

* `make all/build` is better than `./hack/build.sh`

Yes, that's probably my main motivation for Makefile.

oops, brain fart... I actually wanted to say the make all/build is not any better than ./hack/build.sh

[soltysh]

oops, brain fart... I actually wanted to say the make all/build is not any better than ./hack/build.sh

😭 my main reason for Makefile is also the fact that when jumping between repos I'm confident that invoking make will give me binary, except for the installer, currently.

[abhinavdahiya]

This looks abandoned. Please feel free to reopen if you think this change is still useful.

/close

[openshift-ci-robot]

@abhinavdahiya: Closed this PR.

Details

In response to this:

This looks abandoned. Please feel free to reopen if you think this change is still useful.

/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.

[openshift-ci-robot]

@soltysh: The following tests failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
ci/prow/e2e-aws-upgrade	1d08747	link	/test e2e-aws-upgrade
ci/prow/e2e-aws	1d08747	link	/test e2e-aws

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

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. I understand the commands that are listed here.