Git File Bridge information

(Ryan Archer) #1

Hi all,

 

Just now have upgraded to v5.3.0 and very keen to look at the possiblities afforded by using the 'Git File Bridge' asset.

I can't find anything out about it on the http://manuals.matrix.squizsuite.net- is there any information or documentation about it anywhere?

 

Cheers.

(Nic Hubbard) #2

Manuals are only updated for 5.2, but I am sure they are working on 5.3 docs.

(Ryan Archer) #3

ughh, have to wait until next year then... Rebecca_impatient.jpg (45.3 KB)

(Aleks Bochniak) #4

Our recent 'upgrade' was missing the 'Git File Bridge' asset!

(Bart Banda) #5

We are getting through a big back log of features and enhancements to document in the manuals as our resident manuals guy has been on long service leave. Here is some stuff on the bridge in the meantime that might help (taken from the Squizmap idea as the original spec):

 

  1. We're looking at the idea of a new asset type called "Git File Bride" which would be a one-way bridge that pulls files from Git into the Matrix file system. 
  2. After some dev discussion, instead of using the sparse-checkout feature, we'll instead allow the user to configure sub directories on the bridge asset itself. This will make only those sub directories available in the shadow asset tree in the map as well as placed in the data public directory as public assets. This will keep all unused dev files "hidden" and unavailable for use and the imp can just focus on linking to the production files. 
  3. Once connection is established and available, you can then select an option on the bridge to pull the latest files from the specified branch and repo. This then goes and pulls the files to the Matrix file server into a dedicated Git directory under __data/public/git/{asset_id_of_bridge} (for example).
  4. The Git Bridge would need to be able to have URL, and be somehow exposed as an API that can be called by an external Git system. You would then be able to have Git hooks that call the bridge and tell it to do a new Pull from the repo. These calls would need to be authenticated as well somehow.
  5. This file bridge would simply then show file assets from that repo in the form of shadow assets within the Matrix admin interface.
  6. An implementer can then reference these shadow asset files using new keywords that point to the file bridge asset as a base, and then use a modifier to choose which file to reference, for example:
    1. "./?a=2546:css/style.css" would print: "http://www.site.com/__data/assets/git_bridge/0017/2546/css/style.css"
    2. Also the url structure implied above should allow relative url references, e.g. a reference to 'images/roller-skating-parrot.jpg' in 'global.css' could be served from '__data/assets/git_bridge/0017/2546/images/roller-skating-parrot.jpg', which can't currently be done with assets served via '__data' urls.  Since we can't do asset ID references - and the css will be unparsed, we need to be able to reference relatively, which will also simplify using 3rd party plugins etc that work this way. 
    3. Using unique IDs is not possible with dynamic shadow assets. We can instead have a usage screen that tells you which files are being used in what assets. So when you use a git keyword in bodycopy or design, it will create a notice link, and you can find all usages in the usage screen of the Git Bridge.
  7. Similar to the File Bridge in Matrix, you should be able to browse and view the files within the bridge via the asset map: http://manuals.matrix.squizsuite.net/core-assets/chapters/file-bridge#Browsing-and-Viewing-Files
  8. The assumption is also that any files brought over via the Git bridge are mainly aimed for design and template purposes and would be automatically public as they would live in __data/public. If you need to have permission restrictions on some of these files, they should then be managed as normal file assets.
(Bart Banda) #6

Sorry for the delay everyone, but this documentation is up on manuals now: https://manuals.matrix.squizsuite.net/git

(Ryan Archer) #7

Unfortunately get a Page Not Found error when visiting that link Bart.

(Greg Sherwood) #8

There was a space in the URL. The link is: https://manuals.matrix.squizsuite.net/git

(Ryan Archer) #9

Sweeet.

(Ryan Archer) #10

The updated documentation is very clear and well written. Had my first GIT File bridge up and running in no time. It's now great to include GIT version control in our projects. Awesome work guys.

(Ryan Archer) #11

I'm just going to take this thread a little further. I am currently creating a 'Packery' based demo in GitHub complete with folders for the HTML, JS and CSS. Then I nest in the shadow HTML asset created by the GIT File Bridge that has links to JS and CSS in it (the links had to be written with ./?a=####:css/style.css format in the GitHub editor for the links to work when viewing the page).

 

Anyway, I came across a really weird feature. By default, all the spaces in the HTML file coming from the GIT repo are replaced with <br /> tags. Which just breaks my code and ruins the presentation of the page. Now if I go back into the GitHub editor and then select the indent mode to be 'tabs' (in the top right corner of the editor) and then commit the changes - when I refresh the page, everything displays properly and there are no <br /> tags in my nested HTML code.

 

Is this an intentional feature or not? I don't understand how HTML blank spaces are intepreted as <br /> tags when the webhook pushes the updated HTML file through...

(Bart Banda) #12

Not sure, never heard or seen this before. But then again I don't know of anyone else that uses the Github editor. Maybe there was something to do with the initial files when placed in to git? Is there a way to easily replicate this you know?

(Ryan Archer) #13

I will keep my eye on it. Probably not the best idea to place gitHub HTML pages into a nested content object anyway. Best to have standard page in squiz that references JS/CSS libraries via the GIT Bridge. Was just putting the tool through its paces. I'm now changing my workflow to use the Github desktop app so will see how it goes.

(Bart Banda) #14

I reported it in squizmap for our developer to take a look at and we'll fix it in an upcoming release: https://squizmap.squiz.net/matrix/8757

 

 

The issue here is due the way printBody() (the function called by bodycopy container or design to output the asset its painting) is implemented in Physical File asset (which File/Git Bridge uses to represented the repo files). The Physical File was originally implemented for File Bridge asset :class Physical_File { ....
public function printBody()
{ ....
....
$type = $this->getMimeType();

if (strpos($type, 'text') === 0) {
$location = $bridge->getLocationPath();
...
$content = file_get_contents($full_path);
$content = nl2br($content);
}//end if

...

}//end printBody()

So any File Bridge shadow asset with mine type beginning with 'text' will return with all the newlines converted to <br /> tags. While any other file types will return empty content.

One of the implementation (not sure if theres any more other ways) where this issue can be replicated is when nesting the Git/File bridge shadow in a nested content. Nesting any File/Git Bridge shadow asset with file type's mime type definition beginning with "text", will have all types of newlines in the content converted to <br /> tags. Nesting any other type will return empty content.

This is not really a bug though as Git Bridge was not intended to be used in this way in the original spec. However this can be fixed easily in Git Bridge, without affecting the File Bridge behaviour, which I think should be left as it is.