I have a couple of opinions.

1. How about switching the resolver from the target file starting with git://github.com ?

Example:

falco -v git://github.com/org/repo # use GIt resolver
falco -v ./main.vcl # use File resolver

2. Why don't we use https://github.com/google/go-github ?

I understand that the git command is useful for resolving authentication like private repo, but it means that falco has a dependency on git command. Normally git command has been installed on almost the developer's machine but we should discuss it.

Why don't we use https://github.com/google/go-github ?

I started implementing this with https://github.com/go-git/go-git but I thought in the end that it wasnt worth it. Mainly for two reasons:

• Authentication is complicated and it will require us to extend the command line with even more flags.
• We will add a big golang dependency that is used for only a single command

Basically at this point given that we do only one git call it seems like a decent tradeoff not to pull an entire git implementation and rely on a subprocess call. Especially because I didnt have to handle the output and I just take the whole stdout of the process.

How about switching the resolver from the target file starting with git://github.com ?

Does this mean adding the prefix git://github.com for all paths? Or just for the main.vcl. That prefix might not be a bad idea since it is used widely

Does this mean adding the prefix git://github.com for all paths? Or just for the main.vcl. That prefix might not be a bad idea since it is used widely

Yes, for example, if git://github.com/org/repo is provided, it adds to include path and resolves include statements from another git repository via git show command.

And from another perspective, I think the following commands are the same behavior for managing VCLs on another repository:

git clone [email protected]:org/repo # ssh or https
falco -I ./repo path/to/main.vcl

The above syntax is the common use case and clearly divides the matter of concern git authentication I think, so I'm not sure that the worth of supporting git communication (of course git submodule is not a good way, but...)

It is useful for the continuous integration of local development, Or if there are more benefits, please let me know.

git clone [email protected]:org/repo # ssh or https
falco -I ./repo path/to/main.vcl

Sadly this is not exactly the same and this is the problem I run into:

Imagine that you have repo 1 that contains:

• main_1.vcl
• main_2vcl

Then main_1.vcl could depend on version 1 of a dependency and main_2.vcl on version 2. And even within just main_1.vcl it could have a dependency that is on version 1 and another that is on version 2 so you can checkout the repo, you have to show each dependency on the correct version

@davinci26 Hmm, could you show me in detail of use case using github repo?

• What does the version mean? fastly's service version?
• Is there a case of managing VCL across versions?

I could not imagine that some VCL file depends on other versions. In my use case, all VCL files indicate one version and it's the standard way of managing VCL.

@shadialtarsha @ivomurrell could you hear me your opinition on this case?

If I understand correctly than some special tooling is required when deploying VCL that specifies Git versions for dependencies, as Fastly's include statement does not support specifying revisions itself. Unless this format of resolving files via a path:version string is standardised and used across various organisations I'm not sure whether we should be supporting it in the linter. Is this something that needs to be upstreamed, @davinci26?

@ivomurrell I think that it is a good idea to use standard git uri for include paths which make it more upstream friendly and also I think versioned VCL files is a natural progression if you manage a big VCL corpus so this is why I wanted to push it.

Imagine that you have the following scenario:

• helpers.vcl in common repository
• service1.vcl and service2.vcl in a single repository
• service1 gets way way more traffic than service2

Then you want to rollout the helpers.vcl in service2 first for stability reasons and then you roll it our on service1 after you validated first. In that case you have the following:

• time 0: Both service 1 and service 2 are on version a
• time 1: service 2 is updated on version b
• time 2: service 1 is also updated to version b

@davinci26 I can definitely see the utility of the approach you're describing, but the problem still seems to be that the rollout facility depends on custom deployment tooling to parse and resolve the special path:version syntax. I'm not convinced it makes sense to put this in the upstream falco repository rather than keep as a fork you can maintain when we're talking about adding support for a bespoke solution specific to your company 🙂 Is the code you use to resolve the git revisions when making deployments to Fastly available to look at somewhere?

Realized that the TF mode is solving all my problem and I can TF plan to do this for me. I think this is a win-win overall :)

This is no longer needed, thanks a lot for the feedback tho!

See #102