Fix Makefile to take vaules from ENV VAR values

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_TAG_NAME := $(VERSION)
-IMAGE_EXTRA_TAG_NAMES :=
+IMAGE_REGISTRY ?= k8s.gcr.io/nfd
+IMAGE_NAME ?= node-feature-discovery
+IMAGE_TAG_NAME ?= $(VERSION)
+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