File Extension Associations

[zero4573]

I've installed this plugin recently in an attempt to push project documentation into our repositories instead of having them sprawled around in our confluence instance and have recently run into a minor inconvenience.

We currently use Jenkins and author some internal jenkins libraries, these are documented in markdown, however the file extension is ".txt". Unfortunately, according to the jenkins documentation at https://jenkins.io/doc/book/pipeline/shared-libraries/#directory-structure, the extension cannot be changed if we want it to be loaded by the jenkins system’s configured markup formatter, which will provide a custom help menu for the particular step once registered through the jenkins pipeline editor.

As the files are .txt files, they are not rendered as markdown, and thus we get plain text when we try to view the documentation on git4c. From what I could tell, there isn't a place to define how the git4c macro will render a specific file extension.

Is it possible to request a feature for specifying custom file type associations? Either globally, or on a macro level, or even both?

You might even be able to bundle it in with the predefined filters and make whatever is picked up by the filter automatically associated a specific renderer.

[gkopij]

Hi

thank you for reporting the issue and apologize for the long delay. We're just back from holidays and starting again the work on git4c new release Which version of the macro do you use the most? For the single snippet we would add an option to select the render format for the multi page it's a bit difficult, because we Ould force the user to add this option globally. Is that something you need at the global level? Or repository level? There is an option to automatically check for the format, but I don't know yet how much effort it would take to implement and if there is even a need for that.

[zero4573]

Hi @gkopij

We use the single file macro the most, as a lot of times we just reference the README.md files of our repositories. However for this specific scenario, we are using the multi-file macro as it automatically picks up new library documentation when its pushed rather than requiring the authors to create a new confluence page under the parent, and referencing the doc file explicitly.

From our use cases so far, global or repository level would work, as we don't really use the .txt extension (and need to reference it in confluence) anywhere else. However I believe the option with the most flexibility would be the repository level.

Also, to clarify what I meant by automatically check, is to automatically associate a pre-defined filter with a render format. Which, correct me if I am wrong, is effectively defining the option at a global level. This was just a suggestion about on way to implement the proposed feature globally, pay it no mind if this doesn't make any sense.