stefh / ghaction-compressfiles

A GitHub Action for compressing files using Brotli or GZip

Hi 👋, I'm Stef Heyenrath

• 🔭 I’m currently working on WireMock.Net
• 🌱 I’m currently learning more Azure and Blazor

Environments

Languages

Frontends

ghaction-compressfiles's Issues

[Question] Action integration in mkdocs workflow

Thanks for providing this GitHub action! 

I'm currently trying to use your compression action in my mkdocs workflow with GitHub actions but I run into issues with branches/actions. See my test repo and the action docs.

Current workflow

The workflow is simple: whenever someone pushes to the repo, the mkdocs CI action is triggered and the site is deployed. 

The main branch contains raw (editable) markdown files which are then converted to normal html in my gh-pages branch. The gh-pages branch serves for automatic deploy with GitHub Pages.

Idea

I have two possible ideas of how to integrate your compression. 

1. Integrate it directly in the standard gh-pages action. Problem: it does everything automatically and does not offer simple customization. That's the reason why I'd prefer the second idea.
2. Create a third branch called deploy. So when main registers a change, everything is executed as normal and gh-pages is populated with the html files. How could I then use your action to take the input from gh-pages (when ready) compress it with your action and push to deploy? I saw the path variable, but still didn't manage to link the branches and your action. 

It rather might be a question for the mkdocs community but maybe other static site generators like Hugo, Jekyll etc. might profit from it as well.

Allow -n option for gzip

At the moment, this Github Action calls gzip without the -n flag. This means every build produces a new file that checksums to a different checksum.

When deploying your application, you normally could use rsync --checksum flag to deal with the file modification times changing. However, since the produced gzipped files also change their checksum, it means they always gets redeployed, which means in turn the users of the webserver see the file as modified and have to download it again, even though it represents the same resource.

gzip has a flag -n for this, which does not record the original files modification date inside the gzipped archieve, which is designed for determistic builds. At the moment, this Github Action does not have a way to pass custom flags to the gzip command, so it cannot be used.