Push image to 7 digit git sha tag instead of latest tag for master branch changes

[wongma7]

Is this a bug fix or adding new feature? fix

What is this PR about? / Why do we need it?

latest tag is dangerous to use. But releases are infrequent. So push git tag releases so users can take advantage of bugfixes immediately instead of having to wait for a release.

We are working on having more frequent releases starting with the next one. Partly there is the manual effort of compiling changelog (though there is a script), testing (though CI is mostly sufficient), and bottleneck (@leakingtapan may not have time to push out a tag every couple weeks and I/others don't have permissions yet).

What testing is done?

TBH I'm not sure how to test the github workflow but I know HORT_SHA=$(echo $GITHUB_SHA | cut -c -7) works and docs say GITHUB_SHA will be available: https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: wongma7

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 [wongma7]

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

[2uasimojo]

/test pull-aws-efs-csi-driver-e2e

[2uasimojo]

/test pull-aws-efs-csi-driver-e2e

[wongma7]

Test cluster can't come up for some reason ,not sure why.

/retest

[2uasimojo]

/test pull-aws-efs-csi-driver-e2e

[wongma7]

/retest
https://prow.k8s.io/view/gcs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_aws-efs-csi-driver/202/pull-aws-efs-csi-driver-e2e/1276619512052977664
One test failed for unknown reasons

Jun 26 21:32:33.649: INFO: Failed to get logs from node "ip-172-20-71-239.us-west-2.compute.internal" pod "pod-subpath-test-efs-csi-aws-com-preprovisionedpv-hgmj" container "test-container-subpath-efs-csi-aws-com-preprovisionedpv-hgmj": the server rejected our request for an unknown reason (get pods pod-subpath-test-efs-csi-aws-com-preprovisionedpv-hgmj)
�[1mSTEP�[0m: delete the pod'

The other a strange reason that I am not sure how to even begin investigating

Output: mount.nfs4: mounting fs-58e1185d.efs.us-west-2.amazonaws.com:/ failed, reason given by server: No such file or directory

[nckturner]

/lgtm

[2uasimojo]

Is there still a mechanism for making sure the latest tag continues to be updated? I (accidentally) tested this morning with the latest image and the overlays from the master branch, and it freaked out here:

  Warning  FailedMount  2m6s (x5 over 2m14s)  kubelet, ip-10-0-132-140.ec2.internal  MountVolume.SetUp failed for volume "pv-myns1-sv-424108c1-0db54075d8db36379" : kubernetes.io/csi: mounter.SetupAt failed: rpc error: code = Internal desc = Could not mount "fs-424108c1:/" at "/var/lib/kubelet/pods/afc856e2-13a5-4b47-a0b3-644ea4d36d87/volumes/kubernetes.io~csi/pv-myns1-sv-424108c1-0db54075d8db36379/mount": mount failed: exit status 1
Mounting command: mount
Mounting arguments: -t efs -o accesspoint=fsap-0db54075d8db36379,tls fs-424108c1:/ /var/lib/kubelet/pods/afc856e2-13a5-4b47-a0b3-644ea4d36d87/volumes/kubernetes.io~csi/pv-myns1-sv-424108c1-0db54075d8db36379/mount
Output: Traceback (most recent call last):
  File "/sbin/mount.efs", line 1537, in <module>
    main()
  File "/sbin/mount.efs", line 1517, in main
    bootstrap_logging(config)
  File "/sbin/mount.efs", line 1187, in bootstrap_logging
    raw_level = config.get(CONFIG_SECTION, 'logging_level')
  File "/lib64/python2.7/ConfigParser.py", line 607, in get
    raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'mount'

...which I think might be because the node.yaml and latest image are on opposite sides of #196.

[wongma7]

I want to change latest to mean "latest stable version" and instead push master branch changes to master/unstable. But we can't make that change until the next release, In the meantime we can continue pushing to latest.

[2uasimojo]

Okay. As long as I can count on a tagged image working with the YAML from the corresponding commit level, I'm happy. (I confirmed that this morning with the tag for 778131e.) I'm just not sure the current latest matches up with the current tip of the master branch...