Fix Makefile to take vaules from ENV VAR values

make image and make push fails when trying to use an ENV VAR value, as
it is now they can only be overrided.

the Var modified are
GO_CMD
GO_FMT
IMAGE_BUILD_EXTRA_OPTS
IMAGE_BUILD_CMD
IMAGE_PUSH_CMD
IMAGE_REGISTRY
IMAGE_NAME
IMAGE_EXTRA_TAG_NAMES
K8S_NAMESPACE
HOSTMOUNT_PREFIX

This new behaviour has also been updated on the README.

Signed-off-by: Carlos Eduardo Arango Gutierrez <carangog@redhat.com>

Makefile

@@ -1,23 +1,23 @@
 .PHONY: all test yamls
 .FORCE:
 
-GO_CMD := go
-GO_FMT := gofmt
+GO_CMD ?= go
+GO_FMT ?= gofmt
 
-IMAGE_BUILD_CMD := docker build
-IMAGE_BUILD_EXTRA_OPTS :=
-IMAGE_PUSH_CMD := docker push
+IMAGE_BUILD_CMD ?= docker build
+IMAGE_BUILD_EXTRA_OPTS ?=
+IMAGE_PUSH_CMD ?= docker push
 
 VERSION := $(shell git describe --tags --dirty --always)
 
-IMAGE_REGISTRY := k8s.gcr.io/nfd
-IMAGE_NAME := node-feature-discovery
+IMAGE_REGISTRY ?= k8s.gcr.io/nfd
+IMAGE_NAME ?= node-feature-discovery
 IMAGE_TAG_NAME := $(VERSION)
-IMAGE_EXTRA_TAG_NAMES :=
+IMAGE_EXTRA_TAG_NAMES ?=
 IMAGE_REPO := $(IMAGE_REGISTRY)/$(IMAGE_NAME)
 IMAGE_TAG := $(IMAGE_REPO):$(IMAGE_TAG_NAME)
 IMAGE_EXTRA_TAGS := $(foreach tag,$(IMAGE_EXTRA_TAG_NAMES),$(IMAGE_REPO):$(tag))
-K8S_NAMESPACE := kube-system
+K8S_NAMESPACE ?= kube-system
 
 # We use different mount prefix for local and container builds.
 # Take CONTAINER_HOSTMOUNT_PREFIX from HOSTMOUNT_PREFIX if only the latter is specified
@@ -26,7 +26,7 @@ ifdef HOSTMOUNT_PREFIX
 else
     CONTAINER_HOSTMOUNT_PREFIX := /host-
 endif
-HOSTMOUNT_PREFIX := /
+HOSTMOUNT_PREFIX ?= /
 
 KUBECONFIG :=
 E2E_TEST_CONFIG :=

README.md

@@ -282,20 +282,23 @@ capability might be supported but not enabled.
 | DCPOP     | Persistent Memory Support
 
 ### Custom Features
+
 The Custom feature source allows the user to define features based on a mix of predefined rules.
 A rule is provided input witch affects its process of matching for a defined feature.
 
 To aid in making Custom Features clearer, we define a general and a per rule nomenclature, keeping things as
 consistent as possible.
 
 #### General Nomenclature & Definitions
+
 ```
 Rule        :Represents a matching logic that is used to match on a feature.
 Rule Input  :The input a Rule is provided. This determines how a Rule performs the match operation.
 Matcher     :A composition of Rules, each Matcher may be composed of at most one instance of each Rule.
 ```
 
 #### Custom Features Format (using the Nomenclature defined above)
+
 ```yaml
 - name: <feature name>
   matchOn:
@@ -312,6 +315,7 @@ Matcher     :A composition of Rules, each Matcher may be composed of at most one
 ```
 
 #### Matching process
+
 Specifying Rules to match on a feature is done by providing a list of Matchers.
 Each Matcher contains one or more Rules.
 
@@ -321,6 +325,7 @@ of a given Matcher.
 #### Rules
 ##### PciId Rule
 ###### Nomenclature
+
 ```
 Attribute   :A PCI attribute.
 Element     :An identifier of the PCI attribute.
@@ -330,6 +335,7 @@ The PciId Rule allows matching the PCI devices in the system on the following At
 `device`. A list of Elements is provided for each Attribute.
 
 ###### Format
+
 ```yaml
 pciId :
   class: [<class id>, ...]
@@ -343,6 +349,7 @@ At least one Attribute must be specified. Missing attributes will not partake in
 
 ##### UsbId Rule
 ###### Nomenclature
+
 ```
 Attribute   :A USB attribute.
 Element     :An identifier of the USB attribute.
@@ -352,6 +359,7 @@ The UsbId Rule allows matching the USB devices in the system on the following At
 `device`. A list of Elements is provided for each Attribute.
 
 ###### Format
+
 ```yaml
 usbId :
   class: [<class id>, ...]
@@ -365,20 +373,23 @@ At least one Attribute must be specified. Missing attributes will not partake in
 
 ##### LoadedKMod Rule
 ###### Nomenclature
+
 ```
 Element     :A kernel module
 ```
 
 The LoadedKMod Rule allows matching the loaded kernel modules in the system against a provided list of Elements.
 
 ###### Format
+
 ```yaml
 loadedKMod : [<kernel module>, ...]
 ```
  Matching is done by performing logical _AND_ for each provided Element, i.e the Rule will match if all provided Elements (kernel modules) are loaded
  in the system.
 
 #### Example
+
 ```yaml
 custom:
   - name: "my.kernel.feature"
@@ -423,6 +434,7 @@ if `some_kmod1` _AND_ `some_kmod2` kernel modules are loaded __OR__ the node con
 with a PCI vendor ID of `15b3` _AND_ PCI device ID of `1014` _OR_ `1017`.
 
 #### Statically defined features
+
 Some feature labels which are common and generic are defined statically in the `custom` feature source.
 A user may add additional Matchers to these feature labels by defining them in the `nfd-worker` configuration file.
 
@@ -581,6 +593,7 @@ created a shared area for delivering hooks and feature files to NFD.
 
 
 #### A Hook Example
+
 User has a shell script
 `/etc/kubernetes/node-feature-discovery/source.d/my-source` which has the
 following `stdout` output:
@@ -601,6 +614,7 @@ override.namespace/value=456
 ```
 
 #### A File Example
+
 User has a file
 `/etc/kubernetes/node-feature-discovery/features.d/my-source` which contains the
 following lines:
@@ -874,6 +888,7 @@ attribute in the spec template(s) to the new location
 (`<registry-name>/<image-name>[:<version>]`).
 
 ### Customizing the Build
+
 There are several Makefile variables that control the build process and the
 name of the resulting container image.
 
@@ -895,13 +910,24 @@ name of the resulting container image.
 | E2E_TEST_CONFIG            | Parameterization file of e2e-tests (see [example](test/e2e/e2e-test-config.exapmle.yaml)) | *empty*
 
 For example, to use a custom registry:
+
 ```
 make IMAGE_REGISTRY=<my custom registry uri>
 
 ```
+
 Or to specify a build tool different from Docker:
+
+It can be done in 2 ways, by pre-defining the variable 
+
+```
+IMAGE_BUILD_CMD="buildah bud" make
+```
+
+Or By overriding the variable value
+
 ```
-make IMAGE_BUILD_CMD="buildah bud"
+make  IMAGE_BUILD_CMD="buildah bud"
 ```
 
 ### Testing