feat(templates): support same-repo templates using build commit

[ecrupper]

When working with templates that are found in the same repo as the Vela file, any live edits to the templates requires the users to reference their specific branch in the templates block. Example:

templates:
  - name: sample
    source: https://github.com/<org>/<repo>/path/template.yml@feature-branch
    type: github

With this change, users can specify the type file in their templates block, which will automatically fetch the template from the commit associated with the build. Example:

templates:
  - name: sample
    source: path/template.yml
    type:  file

[codecov]

Codecov Report

Merging #713 (68d7183) into main (cd67f9a) will increase coverage by 0.00%.
The diff coverage is 54.83%.

@@           Coverage Diff           @@
##             main     #713   +/-   ##
=======================================
  Coverage   54.79%   54.79%           
=======================================
  Files         216      216           
  Lines       16015    16046   +31     
=======================================
+ Hits         8776     8793   +17     
- Misses       6857     6869   +12     
- Partials      382      384    +2     

Impacted Files	Coverage Δ
compiler/native/expand.go	70.68% <54.83%> (-3.07%)	⬇️

[JordanSussman]

@ecrupper I feel like we should have the type be either github.amrom.workers.devmit or commit-github incase we want to add additional source code systems in the future.

[ecrupper]

@ecrupper I feel like we should have the type be either github.amrom.workers.devmit or commit-github incase we want to add additional source code systems in the provider.

Naming is definitely a pain point with this PR 😅 . I agree github should be somewhere in the name. github.amrom.workers.devmit, github-repo, github-relative, github-local all come to mind...

[cognifloyd]

Very nice!

I think we should stick with commit (or something similar) that does not mention github. See my comment.

I have one nitpick about the test. Otherwise, I say this is good to go!

[wass3r]

this would be really nice for local pipeline execution via vela exec pipeline - even without checking code in. but i think the current implementation doesn't suit itself for that. part of the reason i thought this can be scm agnostic and the type be relative or file. thoughts around that?

[cognifloyd]

this would be really nice for local pipeline execution via vela exec pipeline - even without checking code in. but i think the current implementation doesn't suit itself for that. part of the reason i thought this can be scm agnostic and the type be relative or file. thoughts around that?

Is that what c.local bit does?

server/compiler/native/expand.go

Lines 170 to 179 in 5693244

	case c.local:
	a := &afero.Afero{
	Fs: afero.NewOsFs(),
	}
	bytes, err = a.ReadFile(tmpl.Source)
	if err != nil {
	return bytes, err
	}

I kind of like relative - but that might suggest that it is relative to the current file vs relative to the repo root.
I think I could grow to like file even better. The more I think about this one, I think I like it a lot.

[wass3r]

Is that what c.local bit does?

busted! forgot about that. 🫣

[wass3r]

@cognifloyd i think your feedback is addressed

@ecrupper we will need to add to docs too