I am using a custom theme for syntax highlighting and it seems like the action is not recognizing it. My folder structure is the following:

.
├── config.toml
├── extra-highlight-themes
│   └── modified-nord.tmTheme
├── content
├── LICENSE-Hack.md
├── LICENSE.md
├── public
├── README.md
├── sass
├── static
└── templates

and my configuration is:

highlight_code = true

[extra_syntaxes_and_themes]
extra_highlight_themes = ["extra-highlight-themes",]
highlight_theme = "modified-nord"

This configuration works fine when running zola build locally and zola serve but when pushed to github, there's no syntax highlighting at all.

The cause maybe a wrong configuration because the documentation on custom highlighting is not very extensive and there's no example of how to set it up on zola's example configuration file, but the fact that it works locally make me think that there's an issue with the action.

I am using the Sam theme for my Zola project. I added the theme to my project with

git submodule add https://github.com/janbaudisch/zola-sam.git themes/sam

However, I am receiving the following error.

Starting deploy...
Fetching themes
fatal: Not a git repository (or any parent up to mount point /github/workspace)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
##[error]Docker run failed with exit code 128

Here is my .yaml

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - name: Zola Deploy to Pages
      uses: shalzz/[email protected]
    env:
        TOKEN: ${{ secrets.Token }}

Any thoughts?

Every time the zola-deploy-action runs, my Github pages custom domain is reset in the settings, and I have to manually enter the domain again and click save.

Is there any options for resolve this?

For pull requests it's a good practice to build site before merge to check that everything is fine.
Right now action provides an ability to build with publish only.

I have a huge submodule (LLVM) that the action fetches, although it is not needed. Would it be possible to fetch only submodules that are relevant to zola?

The example script given in the README fails while running.

It fails with the error /entrypoint.sh: line 63: cd: docs: No such file or directory.

When I remove the line BUILD_DIR: docs from the script, it runs successfully.

The script for reference:

on: push
name: Build and deploy on push
jobs:
  build:
    name: shalzz/zola-deploy-action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: shalzz/zola-deploy-action
      uses: shalzz/zola-deploy-action@master
      env:
        PAGES_BRANCH: gh-pages
        BUILD_DIR: docs
        BUILD_FLAGS: --drafts
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Hi! I'm trying to use this action and I'm getting a weird error. Do you have any idea what this is?

Error: config.toml not found in current directory or ancestors, current_dir is /github/workspace

/usr/bin/docker run --name a323981985f2af59dc4711a01e665833cef89b_dcebc4 --label a32398 --workdir /github/workspace --rm -e "BUILD_THEMES" -e "GITHUB_TOKEN" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_ENVIRONMENT" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e "ACTIONS_RESULTS_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/thiagomajesk.github.io/thiagomajesk.github.io":"/github/workspace" a32398:1985f2af59dc4711a01e665833cef89b
Starting deploy...
Building in . directory
Disable safe directory check
Using zola 0.1[9](https://github.com/thiagomajesk/thiagomajesk.github.io/actions/runs/10345174565/job/28631812915#step:3:10).1
Building with flags:
Error: config.toml not found in current directory or ancestors, current_dir is /github/workspace
Building site...

It would be cool to be able to run zola check maybe even as a separate step in the pipeline.

This way, you could detect dead links and so on before deploying them.

adding BUILD_THEMES: false seems to have no effect has no effect and because their is no gitmodules it fail:

Fetching themes
fatal: No url found for submodule path 'themes/tale-zola' in .gitmodules

My config:

on:
  push:
    branches:
      - main
name: Build and deploy on push
jobs:
  build:
    name: shalzz/zola-deploy-action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: shalzz/zola-deploy-action
      uses: shalzz/zola-deploy-action@master
      env:
        PAGES_BRANCH: gh-pages
        TOKEN: ${{ secrets.TOKEN }}
        BUILD_THEMES: false

I checked the source code of this action, and don't understand what it doesn't works.

Hello, I have a Zola shortcode
templates/shortcodes/resize_image.html

And a post using it to render several co-located photos:

content/hack-a-thon-2021/
                     - index.html
                     - photo1.jpeg
                     - photo2.jpeg

Build and serve works fine locally. However, during the GHA, it fails with this error:

 Error: Failed to render content of /github/workspace/content/hack-a-thon-2021/index.md
Reason: Failed to render resize_image shortcode
Reason: Failed to render 'shortcodes/resize_image.html'
Reason: Function call 'resize_image' failed
Reason: `resize_image`: Cannot find path: content/hack-a-thon-2021/rpi-overhead.jpeg

my action is copy-pasted from zola site:

# On every push this script is executed
on: push
name: Build and deploy GH Pages
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: checkout
        uses: actions/checkout@v2
      - name: build_and_deploy
        uses: shalzz/[email protected]
        env:
          # Target branch
          PAGES_BRANCH: gh-pages
          # Provide personal access token
          TOKEN: ${{ secrets.TOKEN }}

master...knzai:zola-deploy-action:master

So I meant to just add in the ability to keep history on gh-pages... and I got carried away.

This is a complete rewrite into decomposed composite actions. Let me know if this direction is of any interest, or I should spin it off as a separate project.

Next (well after fixing history on gh-pages) I'd probably break it down a bit more and see if I could use an existing deploy-to-gh action and make this just zola that could be used with that, or push to sfto/whatever, or heroku (why? cause people) etc. If it were just zola CLI and solid, we could ask zola team to move it under their org as the official actions/zola!

Let me know thoughts and interest. If you want make me a collab and I'll make a PR with any required changed.

I get:

Run shalzz/[email protected]
  env:
    BUILD_DIR: .
    PAGES_BRANCH: main
    GITHUB_TOKEN: ***
    REPOSITORY: apirogov/apirogov.github.io
/usr/bin/docker run --name c9a4a598e4a64f5f8c4c0ea647e7d47c92e22d_2ae025 --label c9a4a5 --workdir /github/workspace --rm -e "BUILD_DIR" -e "PAGES_BRANCH" -e "GITHUB_TOKEN" -e "REPOSITORY" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_ENVIRONMENT" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/website-source/website-source":"/github/workspace" c9a4a5:98e4a64f5f8c4c0ea647e7d47c92e22d
Starting deploy...
Building in . directory
error: wrong number of arguments, should be 2
Set safe directories
usage: git config [<options>]
...

The lastest release possibly has a typo in the path that was added or the wildcard is not working correctly?

With the previous version I have no issues.

Your Dockerfile currently contains 13 steps. Because every step/instruction is saved as a layer (link I think), every step adds an overhead of 1 second spent snapshotting the filesystem (link to timestamped logs). And worse yet, these layers are discarded when the GitHub Actions build completes, and when I push an updated Zola site to GitHub, it recomputes the entire Docker image from scratch!

One solution is to remove as many steps as possible from the Dockerfile. I took it one step further and removed my custom Dockerfile altogether, instead relying on a custom entrypoint pointing within my repository clone. Since I had vendored this action in my repo, I decided to mimic Zola's GitLab Pages docs (link), and changed the action.yaml to say:

runs:
  using: 'docker'
  image: 'alpine:latest'
  entrypoint: '.github/actions/zola-deploy-action/install.sh'

Note that the entrypoint I used is non-portable, and I don't know how to adapt it to work in an action usable by other repositories.

install.sh installs the necessary packages (bash coreutils git zola), locates $SCRIPTPATH, then runs exec "$SCRIPTPATH/entrypoint.sh". One advantage is that Alpine's apk package manager is faster (2-3 seconds) than apt-get (7 seconds), but it could also be that I don't install wget and that reduces the amount of work apk needs to perform.

Other changes

Additionally I modified entrypoint.sh to remove git submodule update --init --recursive and the surrounding code, and instead modified my own workflow to checkout submodules:

      uses: actions/[email protected]
      with:
        submodules: recursive

I'm not sure if this is faster or not.

as title

The build has been failing for me since yesterday, since I pushed a new commit. I am getting the same error as in actions/runner-images#6775 and the issue actually might be related to runner image, but it is affecting this zola deploy action.

Rolling back to 0.16.1-1 for now :/

The .gitignore file generated from zola build has */ in it. This seems to prevent zola-deploy-action from copying the subfolders from the output folder. To get my website working, I had to manually copy these subfolders to the gh-pages branch.

I don't know whether this is a Zola issue, a zola-deploy-action issue, or a template issue. I suspect that it is not a template issue but I'm not sure. I have also raised this issue here: Zola discourse: Gitignore in public folders preventing websites rendering

FYI, here is my .gitignore in the /public folder created after zola build:

*/
!/helpers

Cheers!

I appear to be getting the same error mentioned in #72, however running zola build locally succeeds as expected.

The error I'm getting in my builds is linked here:
https://github.com/Arzte/arzte.github.io/actions/runs/4809565754/jobs/8989876614#step:4:33

The workflow file I'm using is here:
https://github.com/Arzte/arzte.github.io/blob/main/.github/workflows/main.yml

Let me know if there's any additional information I could provide to help resolve this.

I have a submodule that contains the Sass for Bulma under my sass/ directory, which is causing a failure when fetching the contents despite #63's changes.

Here's the log from the run:

 Starting deploy...
Building in . directory
Set safe directories
Fetching themes
Submodule 'sass/bulma' ([email protected]:jgthms/bulma.git) registered for path 'sass/_vendor/bulma'
Cloning into '/github/workspace/sass/_vendor/bulma'...
fatal: detected dubious ownership in repository at '/github/workspace/sass/_vendor/bulma'
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace/sass/_vendor/bulma
Unable to fetch in submodule path 'sass/_vendor/bulma'; trying to directly fetch 3e00a8e6d0d0e566d507328f0185ef84854effba:
fatal: detected dubious ownership in repository at '/github/workspace/sass/_vendor/bulma'
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace/sass/_vendor/bulma
Fetched in submodule path 'sass/_vendor/bulma', but it did not contain 3e00a8e6d0d0e566d507328f0185ef84854effba. Direct fetching of that commit failed.

Adding an empty .nojekyll file in the generated branch would tell GitHub not to build the site with Jekyll, which is unnecessary, and treat it as a static site. Thus, it would improve performance (along with fixing rare issues I think).

Hi there,

first of all: thank you for this action - I've used it a couple of times for my personal website.
I really like using Zola but there's one thing it can't do: import npm modules.
In order to solve this I've figured that I would have to use some kind of bundler - I've picked RollUp to do so.

This also means that I have to bundle everything after building zola and before deploying.
Luckily your action has a BUILD_ONLY flag.

Here is what I thought I could do and tried:

• Build Zola into a directory called dist
• Run RollUp in this directory to resolve npm imports
• Deploy that

When doing so I get this error:
error: Found argument '--config' which wasn't expected, or isn't valid in this context

My customized action looks like this:

on: push
name: Build, Bundle & Deploy
jobs:
  build-bundle-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - run: mkdir dist
      - name: Zola Build 
        uses: shalzz/zola-deploy-action@master
        env:
          # Target branch
          PAGES_BRANCH: gh-pages
          # Provide personal access token
          BUILD_DIR: dist
          BUILD_ONLY: true
          BUILD_FLAGS: --config config.live.toml
          TOKEN: ${{ secrets.GH_PAGES }}
      - name: Install NPM dependencies & bundle w/ Rollup
        uses: actions/setup-node@v2
        with:
          node-version: '16'
      - run: npm install
      - run: sudo npm run build-rollup-live
      - run: |
          cd dist
          git init
          git config user.name "GitHub Actions"
          git config user.email "[email protected].${GITHUB_HOSTNAME}"
          git add .
          git commit -m "Deploy ${TARGET_REPOSITORY} to ${TARGET_REPOSITORY}:$remote_branch"
          git push --force "${remote_repo}" master:${remote_branch}

          echo "Deploy complete"

So it's mostly like yours. As you can see I was trying to use BUILD_FLAGS with the --config flag and a config file.
The relevant part of this file looks like this:

base_url = 'https://tony-spegel.com'
output_dir = 'dist'

The npm script build-rollup-live I'm trying to run does this: rollup --config rollup.config.live.js
The config which should be used here would be:

import { nodeResolve } from '@rollup/plugin-node-resolve';
import replace from '@rollup/plugin-replace';

export default {
    input: 'dist/index.js',
    output: {
        dir: 'dist/',
        format: 'es',
        sourcemap: false,
    },
    plugins: [
        nodeResolve(),
        replace({
            preventAssignment: true,
        }),
    ],
};

Can you help me out here? I'd really appreciate it if you can push me in the right direction or give me an advice.
Thank you and have a nice weekend, please tell me if I can add anything to make things clearer

I opened an issue about this a few months ago which I closed because I was using an outdated version of zola.

I am using a custom highlighting theme called darker-nord. The way I have set it up is the following.

I have this in my config.toml file:

[markdown]
# Code highlighting
highlight_code = true
# Custom theme
extra_syntaxes_and_themes = ["extra-highlight-themes"]
highlight_theme = "darker-nord"

and the following file structure:

.
├── config.toml
└── extra-highlight-themes
    └── darker-nord.tmTheme

This works fine when running it locally, but the github action fails to build the site:

Error: Highlight theme darker-nord defined in config does not exist.

Hey, can add support for 0.17.0?

Thanks

Now it uses git init and git push --force so that the gh-pages branch will be refreshed on each commit. Can we keep the commit history instead?

Thank you very much for your hard work it is much appreciated. Just one stumbling block that I came across trying to use this.

Background

I was building with zola locally and outputting to "docs" instead of "public" then pushing to GitHub but decided to switch to using GitHub actions.

Error

I kept getting the error /entrypoint.sh: line 83: cd: public: No such file or directory and wasn't really able to understand it at first. Eventually I realized that the actual error message was caused by cd: public and that generated the No such file or directory not because it couldn't find /entrypoint.sh.

Resolution

I changed from having zola output to "docs" back to "public" and then the build in the GitHub action succeed.

Suggestion

Maybe include in the readme that the output folder from zola must be the default of "public" since it appears that this output folder is expected by the script.

I use load_data function to access file from static folder of my repository (and build directory for Github actions). Everything was fine for TravisCI.
https://github.com/SamaraITCommunity/site/actions/runs/76490257

Looks like Docker runner fails to retrieve right path when compiles templates during zola build.
Will try to find a root cause and submit a PR, but maybe I missed something and there is no problem in zola-deploy-action.

I was having this error when setting up my website (https://github.com/naps62/naps62.github.io)

In my previous setup, with gatsby, I had this:

git remote set-url origin https://naps62:${{ secrets.GITHUB_TOKEN }}@github.com/naps62/naps62.github.io

notice that I'm using naps62:TOKEN instead of just TOKEN
As a hotfix to make this action work, I added naps62: as a prefix to the secret string.

Is this something I'm missing, like a permission on the token itself? or is it a bug with how this action uses the token?

Building works locally but in github actions it's failing on resize_image with the error:

Error: Reason: Function call 'resize_image' failed
Error: Reason: `resize_image`: Failed to read image: /github/workspace/content/gallery/the-amazing-spider/img.png

The browser at least can open the image in question just fine: https://github.com/Tattomoosa/mattotousa.art/blob/main/content/gallery/the-amazing-spider/img.png

Hi, I use this action to deploy my zola project, but something was wrong.

 shalzz/zola-deploy-action2s
##[error]Docker run failed with exit code 1
Run shalzz/zola-deploy-action@master
/usr/bin/docker run --name dd9e73cd6edb889eab4a5fb3f12d842d35afc6_d29fdd --label dd9e73 --workdir /github/workspace --rm -e PAGES_BRANCH -e TOKEN -e HOME -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e GITHUB_ACTIONS=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/gxyz.github.io/gxyz.github.io":"/github/workspace" dd9e73:cd6edb889eab4a5fb3f12d842d35afc6
Set the GITHUB_TOKEN env variable.
##[error]Docker run failed with exit code 1

Relevant Versions

zola-deploy-action version 0.16.1
checkout version 3.3.0

Problem

I keep experiencing the following issue while using the action:

fatal: detected dubious ownership in repository at '/github/workspace'
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace

I've traced it to the call in entrypoint.sh to fetch submodule themes.

Looking further it's weird because within checkout there is an option to add the repository directory as a safe directory which is by default set to true, but then somewhere in the process of the action being moved into the docker container the directories change (I've only a basic understanding of how actions work) and thus the permissions get reset.

It's my theory that a fix is as simple as adding a line calling git config --global --add safe.directory /github/workspace before the chunk to update the submodules but again I've not much experience making actions so I'm uncertain.

Hi,

Would be nice to have the latest releases on the marketplace.
When pointing to master, it rebuilds the image every time it runs instead of just pulling.

Thank you

In some cases, users might prefer to use the older Zola version (for whatever reason), instead of relying on the version hardcoded by the action implementation.

In my case, I would prefer to use Zola 0.10.1 to use exactly the same version as provided by my OS. This way I would be able to control when I want to upgrade my site to the next Zola release.

Prompted by: getzola/zola#1076

I propose adding CUSTOM_DOMAIN env variable that will be automatically written to static/CNAME.
It's more logical to configure it in one place than using CNAME file for custom domain and env. variables for all other settings

I got this error while trying to publish my github pages.
fatal: Authentication failed for 'https://github.com/amrirasyidi/pmed.git/'

I followed the instruction from here and use the script in this repo as the yaml file as such:

name: Zola on GitHub Pages

on: 
 push:
  branches:
   - master

jobs:
  build:
    name: Publish site
    runs-on: ubuntu-latest
    steps:
    - name: Checkout master
      uses: actions/[email protected]
    - name: Build and deploy
      uses: shalzz/[email protected]
      env:
        GITHUB_TOKEN:

I provided the GITHUB_TOKEN ofc.

What can I do to fix this error?

Hi!

Would it be possible to integrate support for using GITHUB_TOKEN for deploying as an alternative to using personal access tokens?

I noticed that e.g. this action seems to say that GITHUB_TOKENs can be used for gh-pages deployments, wonder if a similar approach could be added here?

Thanks!

This is possible because you can see it being used here

I personally would just checkout the repo with ssh-key instead of running an agent step. But both cases can be supported with just pushing to the remote directly with token absent.

I'm following your example on my site: https://github.com/therealprof/therealprof.github.io/blob/code/.github/workflows/zola.yml

Yet, despite having set PAGES_BRANCH to master (due to: User pages must be built from the master branch.) it decided to deploy to gh-pages instead.

see:

https://github.com/flxzt/mercury/actions/runs/4523922956/jobs/7967401062

I am using the example shown in the readme:

name: Zola on GitHub Pages

on: 
 push:
  branches:
   - main

jobs:
  build:
    name: Publish site
    runs-on: ubuntu-latest
    steps:
    - name: Checkout main
      uses: actions/[email protected]
    - name: Build and deploy
      uses: shalzz/[email protected]
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Probably related to the fix for #52

In my github actions, I'm getting the following error

Starting deploy...
Fetching themes
fatal: detected dubious ownership in repository at '/github/workspace'
To add an exception for this directory, call:

	git config --global --add safe.directory /github/workspace

Not sure how to fix it. I've tried setting set-safe-directory: '*' but that doesn't seem to work.

The latest changes in 453548f add double quotes around build flags. This will break Zola when no build flags are defined:

$ zola build ""
error: Found argument '' which wasn't expected, or isn't valid in this context

As the default instructions for running this action pin it to the latest commit in the master branch, this temporarily broke my deployment. (I pinned it to the previous commit now instead.)

I think it's worth making a release v0.17.3 with the latest fix for the dreaded error described in #72.
The latest version on master seems to address all issues, and this is summarized below.

1. The '*' signs pointing to the sass and themes directories are not playing well with the Set safe directories portion of the pipeline
2. #72 attempted to fix this, and it was tested by multiple people (and worked)
3. This comment confirms that the fix worked on repos with git submodules
4. Multiple others (including myself) have confirmed that the latest version on master works for relatively complex sites that depend on sass, but not git submodules.

All in all, I think the fix on master should be released as a version so that folks can make the choice if they want to continue using v0.17.2 (which didn't work for a lot of us), or v0.17.3, which works for others. Pinning the version number makes a lot more sense than using shalzz/zola-deploy-action@master in the longer term.

Thanks for all the work on this btw!

Currently, if this action runs on a self-hosted Github instance that has a different hostname than github.com, the deployment will fail given the following line in entrypoint.sh

remote_repo="https://${GITHUB_TOKEN}@github.com/${TARGET_REPOSITORY}.git"

Would you be open to a PR adding the hostname as a parameter on the action so it can be compatible w/ self-hosted/enterprise environments. Something like:

remote_repo="https://${GITHUB_TOKEN}@${GITHUB_HOSTNAME}/${TARGET_REPOSITORY}.git"

Happy to do it if this sounds of interest!