Add support to embed source metadata from git

[imnitishng]

Summary

Add support to add source metadata from git, to complete #1280

• Support current branch refs
• Support current tag refs
• Support git describe --tags --always
• Support git remote
• Add unit tests
• Add acceptance tests
• Clean and organize code with proper error handling

Output

Before

After

Documentation

• Should this change be documented?
  • Yes, see #___
  • No

Related

Resolves #1137

[dfreilich]

This looks like a really great start!

Our pkg/client directory is already pretty full, and we seem to typically put our direct commands there. I would instead suggest putting the metadata.go file (and accompanying test) in the pkg/project/v2 directory). What do you think, @jromero ?

[imnitishng]

I would instead suggest putting the metadata.go file (and accompanying test) in the pkg/project/v2 directory). What do you think, @jromero ?

Once this is confirmed by others, I'll move the files
Working on fixing failing tests for now.

---

There is a couple of things on git vs our implementation of the commands that I wanted to point out here

• git describe --always returns the short hash of a commit, whose length could vary based on the number of commits (to be unique) in the repository. So for now I went with returning the full commit hash.
  • In the same way full hash is used to generate the tag in the case if the tag exists in a different branch from HEAD, more details on how this tag is generated by git. So git would output v1.0.4-14-g2414721 but this implementation would output v1.0.4-14-g2414721234l23wer323sas58sd8k.
    • The prefix -g here denotes that the tag was made using git SCM, since we are only dealing with git repositories here for now, could we omit this?
• In case of multiple tags git describe --tags --always priortizes annotated tags over unannotated and if there are multiple tags of the same type then they are sorted based on creation date for annotated tags and alphabetical order for unannotated tags, this behaviour was observed by me during testing, hence I have implemented it in the logic.

I am not too sure how to write acceptance tests for this, (are they even required or not?) but if we decide on writing it then we'll probably have to create some dummy files and folders that act as our git repository to test on. Let me know if there is another approach available.

[codecov]

Codecov Report

Merging #1444 (58c1f56) into main (da32cb8) will decrease coverage by 0.10%.
The diff coverage is 87.60%.

@@            Coverage Diff             @@
##             main    #1444      +/-   ##
==========================================
- Coverage   81.38%   81.29%   -0.09%     
==========================================
  Files         152      154       +2     
  Lines        9864    10014     +150     
==========================================
+ Hits         8027     8140     +113     
- Misses       1360     1393      +33     
- Partials      477      481       +4     

Flag	Coverage Δ
os_linux	80.01% <87.60%> (-0.13%)	⬇️
os_macos	77.48% <87.60%> (-0.06%)	⬇️
os_windows	81.17% <87.60%> (-0.08%)	⬇️
unit	81.29% <87.60%> (-0.09%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

[imnitishng]

I might also need some pointers on the failing test cases, not sure what is happening and it's also taking a long time for it to complete.

[jromero]

I am not too sure how to write acceptance tests for this, (are they even required or not?) but if we decide on writing it then we'll probably have to create some dummy files and folders that act as our git repository to test on. Let me know if there is another approach available.

I'm going to merge this as is given the code coverage at the unit level. I'm working on refactoring the acceptance test suite to be easier to work with. As part of that work, I'll see if we can test this set of functionality as well.