use subfolders to deliver page #59

Tealk commented 2022年02月18日 22:32:48 +01:00

Hello,

there are a lot of tools which generate html web pages e.g. Hugo.
Currently you need 2 repos if you want to develop and deliver a website, but if you could specify a subfolder for pages this would be possible in one repo.

Maybe you could write something like webside.domain public/ in the .domain file then the webserver redirects to the folder public when the webside.domai is called.

Hello, there are a lot of tools which generate html web pages e.g. Hugo. Currently you need 2 repos if you want to develop and deliver a website, but if you could specify a subfolder for pages this would be possible in one repo. Maybe you could write something like `webside.domain public/` in the .domain file then the webserver redirects to the folder public when the webside.domai is called.

adam commented 2022年02月21日 12:48:25 +01:00

I think this is somewhat of a duplicate of this, which was closed with the recommendation to use a pages branch for the generated static site. As far as I can tell, @momar is working on the git plugin to automate this, as outlined in #51.

I think I'm in a similar place as you — also using Hugo and looking for some convenient deployment process. I saw you tried a script to automate this, but apparently it is not working properly.

I might also have a look at it in the future, but if you, or anyone, has a convenient script/process to deploy a Hugo site to Codeberg pages, I think it would be greatly appreciated 😊.

I think this is somewhat of a duplicate of [this](https://codeberg.org/Codeberg/Community/issues/410), which was closed with the recommendation to use a `pages` branch for the generated static site. As far as I can tell, @momar is working on the git plugin to automate this, as outlined in #51. I think I'm in a similar place as you — also using Hugo and looking for some convenient deployment process. I saw [you tried a script to automate this](https://codeberg.org/Codeberg/Community/issues/410#issuecomment-372490), but apparently it is not working properly. I might also have a look at it in the future, but if you, or anyone, has a convenient script/process to deploy a Hugo site to Codeberg pages, I think it would be greatly appreciated 😊.

Tealk commented 2022年02月21日 12:54:11 +01:00

But why use git incorrectly when it would be possible to simply specify a subfolder as webroot?

Then you could continue to keep the git standards and still deliver the website.
Currently I also find it very unfortunate that you need a group for each website, I would have e.g. 2 Webseitendie belong to the same group but so I can not deliver.

But why use git incorrectly when it would be possible to simply specify a subfolder as webroot? Then you could continue to keep the git standards and still deliver the website. Currently I also find it very unfortunate that you need a group for each website, I would have e.g. 2 Webseitendie belong to the same group but so I can not deliver.

adam commented 2022年02月21日 13:05:44 +01:00

@Tealk yes, I understand — I'm also used to building Hugo to a subdirectory, which is what I do with GitHub pages, so if Codeberg pages supported it, it would be the most convenient option for me.

@Tealk yes, I understand — I'm also used to building Hugo to a subdirectory, which is what I do with GitHub pages, so if Codeberg pages supported it, it would be the most convenient option for me.

momar commented 2022年02月21日 13:48:37 +01:00

The subfolder-as-webroot approach unfortunately causes quite some overhead, as all the content with all changes will be there twice. That's why the "force-push to an otherwise empty branch" approach is a bit more lightweight - it also makes it easier to avoid an infinite loop in the CI.

But, I agree that using it is currently quite complex, and it seems like GitHub switched to subdirectories at some point as well. We might add that later, but for now I'd prefer to postpone this.

The subfolder-as-webroot approach unfortunately causes quite some overhead, as all the content with all changes will be there twice. That's why the "force-push to an otherwise empty branch" approach is a bit more lightweight - it also makes it easier to avoid an infinite loop in the CI. But, I agree that using it is currently quite complex, and it seems like GitHub switched to subdirectories at some point as well. We might add that later, but for now I'd prefer to postpone this.

Tealk commented 2022年02月21日 13:53:15 +01:00

The subfolder-as-webroot approach unfortunately causes quite some overhead, as all the content with all changes will be there twice.

i don't understand, why are the changes present twice?

> The subfolder-as-webroot approach unfortunately causes quite some overhead, as all the content with all changes will be there twice. i don't understand, why are the changes present twice?

momar commented 2022年02月21日 13:57:57 +01:00

Once in the Hugo source, and once in the subdirectory. When changing something & building it, the change exists in the source and in the build result, and both are committed & pushed to the server. With the extra branch & force-pushing, while there are still source & build result stored in Git, changes to the built files are overwritten (or at least cleaned up from time to time) instead of unneccessarily keeping the whole history.

It's not too bad though in most cases, I agree that we can offer both, but we already have quite a bit of work to do in this repo.

I believe this issue is basically "don't store generated files in Git" vs. "don't use orphan branches in Git". 🙈

Once in the Hugo source, and once in the subdirectory. When changing something & building it, the change exists in the source and in the build result, and both are committed & pushed to the server. With the extra branch & *force-pushing*, while there are still source & build result stored in Git, changes to the built files are overwritten (or at least cleaned up from time to time) instead of unneccessarily keeping the whole history. It's not too bad though in most cases, I agree that we can offer both, but we already have quite a bit of work to do in this repo. I believe this issue is basically "don't store generated files in Git" vs. "don't use orphan branches in Git". 🙈

Tealk commented 2022年02月21日 14:23:18 +01:00

I do not know if I have understood it correctly, but I also have a history when I create the website as a separate repo?
Here for example https://codeberg.org/ButterflyAspect/pages

I have my code for the website here: https://codeberg.org/ButterflyAspect/page-source

the difference would be only that the pages folder would be in page-source and only this would be delivered.

And just because you make a push of the source code you do not necessarily have a change in the delivered files. Normally you develop in develop and then it comes into the master which is then compiled and comes into the pages folder.

I could create the same "overhead" when writing a pre-push hook:

#!/bin/sh
hugo
git -C "public" add . || echo "cant git add"
git -C "public" commit -q -m "publish web update" || echo "cant git commit"
git -C "public" push --force || echo "cant git push"
exit 0

So if someone works uncleanly, you will always have problems, but I think it helps to educate.

I do not know if I have understood it correctly, but I also have a history when I create the website as a separate repo? Here for example https://codeberg.org/ButterflyAspect/pages I have my code for the website here: https://codeberg.org/ButterflyAspect/page-source the difference would be only that the pages folder would be in page-source and only this would be delivered. And just because you make a push of the source code you do not necessarily have a change in the delivered files. Normally you develop in develop and then it comes into the master which is then compiled and comes into the pages folder. I could create the same "overhead" when writing a pre-push hook: ``` #!/bin/sh hugo git -C "public" add . || echo "cant git add" git -C "public" commit -q -m "publish web update" || echo "cant git commit" git -C "public" push --force || echo "cant git push" exit 0 ``` So if someone works uncleanly, you will always have problems, but I think it helps to educate.

adam commented 2022年02月21日 14:30:35 +01:00

The subfolder-as-webroot approach unfortunately causes quite some overhead, as all the content with all changes will be there twice. That's why the "force-push to an otherwise empty branch" approach is a bit more lightweight - it also makes it easier to avoid an infinite loop in the CI.

But, I agree that using it is currently quite complex, and it seems like GitHub switched to subdirectories at some point as well. We might add that later, but for now I'd prefer to postpone this.

I see, thanks for the quick response and all the work on Codeberg pages @momar 😊.

I think that even though GitHub switched to subdirectories, the default is to use a GitHub action that builds the source and pushes it to a gh-pages branch, from where the site is hosted. So if I understand correctly, it seems just like what Codeberg is doing with the pages branch — it is just not convenient to do all of this manually, and the GH action helps with that.

So even though I still like the possibility of specifying a subdirectory, I think the current approach with the pages branch could also work, provided there are instructions or a script on how to build the static site to the pages branch and push. Ideally, this could be a Codeberg-CI workflow?

In the meantime, if anyone has a script to automatically build the Hugo static page, commit the generated site to the pages branch and force push, that'd be awesome!

> The subfolder-as-webroot approach unfortunately causes quite some overhead, as all the content with all changes will be there twice. That's why the "force-push to an otherwise empty branch" approach is a bit more lightweight - it also makes it easier to avoid an infinite loop in the CI. > > But, I agree that using it is currently quite complex, and it seems like GitHub switched to subdirectories at some point as well. We might add that later, but for now I'd prefer to postpone this. I see, thanks for the quick response and all the work on Codeberg pages @momar 😊. I think that even though GitHub switched to subdirectories, the default is to use a GitHub action that builds the source and pushes it to a `gh-pages` branch, from where the site is hosted. So if I understand correctly, it seems just like what Codeberg is doing with the `pages` branch — it is just not convenient to do all of this manually, and the GH action helps with that. So even though I still like the possibility of specifying a subdirectory, I think the current approach with the `pages` branch could also work, provided there are instructions or a script on how to build the static site to the `pages` branch and push. Ideally, this could be a Codeberg-CI workflow? In the meantime, if anyone has a script to automatically build the Hugo static page, commit the generated site to the `pages` branch and force push, that'd be awesome!

Tealk commented 2022年02月21日 14:45:44 +01:00

I think that even though GitHub switched to subdirectories, the default is to use a GitHub action that builds the source and pushes it to a gh-pages branch, from where the site is hosted. So if I understand correctly, it seems just like what Codeberg is doing with the pages branch — it is just not convenient to do all of this manually, and the GH action helps with that.

Really GitHub does it that way with the brench?

In the meantime, if anyone has a script to automatically build the Hugo static page, commit the generated site to the pages branch and force push, that'd be awesome!

Unfortunately, I only managed to put together the source code and the build code. Which also makes sense because the repo is not empty.

> I think that even though GitHub switched to subdirectories, the default is to use a GitHub action that builds the source and pushes it to a `gh-pages` branch, from where the site is hosted. So if I understand correctly, it seems just like what Codeberg is doing with the `pages` branch — it is just not convenient to do all of this manually, and the GH action helps with that. Really GitHub does it that way with the brench? > In the meantime, if anyone has a script to automatically build the Hugo static page, commit the generated site to the pages branch and force push, that'd be awesome! Unfortunately, I only managed to put together the source code and the build code. Which also makes sense because the repo is not empty.

adam commented 2022年02月22日 20:39:49 +01:00

Really GitHub does it that way with the brench?

Yup, I don't have the source now, but I used to host my Hugo site on GitHub pages, and they had a workflow that would take the source files that you pushed to the main branch, run hugo, build the static site, and push the static site files to a gh-pages branch from which the site was hosted.

So back to our situation.

I managed to stumble upon this discussion about a similar problem, where I liked this answer the most.

Basically have the subdirectory where hugo builds the static site be the pages branch of the website repository, and have it in .gitignore of the whole repository, such that we don't need to have the built files in version control.

With this in mind, I made the following shell script, which builds the hugo site in a build subdirectory and force pushes the built files of the static site to the pages branch of this repository, where Codeberg hosts the static site from.

Now I can only have my source files in version control, and always force-push the latest build to pages branch, like @momar suggested.

Here is the script for reference.

#! /bin/bash

build_directory="build"
build_branch="pages"
# delete previous site built, if it exists
if [ -d "$build_directory" ]; then
 echo "Found previous site build, deleting it"
 rm -rf $build_directory
fi
# get remote origin url, e.g. https://codeberg.org/user/repo.git
remote_origin_url=$(git config --get remote.origin.url)
# generate hugo static site to `build` directory
hugo --destination $build_directory
# initialize a git repo in build_directory and checkout to build_branch
cd $build_directory
git init
git checkout -b $build_branch
# ignore macOS system files
echo ".DS_Store" > .gitignore
# stage all files except .gitignore (don't want it in the static site)
git add -- . ':!.gitignore'
# commit static site files and force push to build_branch of the origin
git commit -m "build: update static site"
git remote add origin $remote_origin_url
git push --force origin $build_branch

> Really GitHub does it that way with the brench? Yup, I don't have the source now, but I used to host my Hugo site on GitHub pages, and they had a workflow that would take the source files that you pushed to the `main` branch, run hugo, build the static site, and push the static site files to a `gh-pages` branch from which the site was hosted. So back to our situation. I managed to stumble upon [this discussion](https://stackoverflow.com/questions/2386662/git-put-a-branch-in-a-subdirectory) about a similar problem, where I liked [this answer](https://stackoverflow.com/a/41589217) the most. Basically have the subdirectory where hugo builds the static site _be_ the `pages` branch of the website repository, and have it in `.gitignore` of the whole repository, such that we don't need to have the built files in version control. With this in mind, I made [the following shell script](https://codeberg.org/adam/website/src/branch/main/deploy.sh), which builds the hugo site in a `build` subdirectory and force pushes the built files of the static site to the `pages` branch of this repository, where Codeberg hosts the static site from. Now I can only have my source files in version control, and always force-push the latest build to `pages` branch, like @momar suggested. Here is the script for reference. ```bash #! /bin/bash build_directory="build" build_branch="pages" # delete previous site built, if it exists if [ -d "$build_directory" ]; then echo "Found previous site build, deleting it" rm -rf $build_directory fi # get remote origin url, e.g. https://codeberg.org/user/repo.git remote_origin_url=$(git config --get remote.origin.url) # generate hugo static site to `build` directory hugo --destination $build_directory # initialize a git repo in build_directory and checkout to build_branch cd $build_directory git init git checkout -b $build_branch # ignore macOS system files echo ".DS_Store" > .gitignore # stage all files except .gitignore (don't want it in the static site) git add -- . ':!.gitignore' # commit static site files and force push to build_branch of the origin git commit -m "build: update static site" git remote add origin $remote_origin_url git push --force origin $build_branch ```

Tealk commented 2022年02月22日 21:02:24 +01:00

@adam where and how did you use the .gitignore file?

you should also query which brench you are using and only use the master brench for creating the website, here is how i did it:
https://codeberg.org/Tealk/Git-Hooks_examples/src/branch/master/pre-push%20git%20hugo

but that still only works with a pages repo? or can the repo then be called whatever it wants?

@adam where and how did you use the .gitignore file? you should also query which brench you are using and only use the master brench for creating the website, here is how i did it: https://codeberg.org/Tealk/Git-Hooks_examples/src/branch/master/pre-push%20git%20hugo but that still only works with a pages repo? or can the repo then be called whatever it wants?

adam commented 2022年02月22日 22:38:10 +01:00

@adam where and how did you use the .gitignore file?

I just have a .gitignore file in the main branch of my website repository, and in that .gitignore file I have the build subdirectory added, which is the output directory for hugo (when running hugo --destination build).

The shell script from my previous comment builds the whole site into this subdirectory by running hugo --destination build, so that none of the built files are checked into version control of the main branch of the git repo.

Then all of the static files are commited and force-pushed to the pages branch in the script.

you should also query which brench you are using and only use the master brench for creating the website, here is how i did it:
https://codeberg.org/Tealk/Git-Hooks_examples/src/branch/master/pre-push%20git%20hugo

I just use one branch for my website source files, the main branch, so I haven't done any checks of what branch I'm in. I haven't tried your script, but from what I see it just commits and force-pushes the contents of the public subdirectory (which I assume is the output directory of hugo where the statically built site files are) to the master branch? Again, I'm not sure if I got that correctly, but then it wouldn't work with the current Codeberg pages setup, where the static files need to be in a pages branch of the repo.

but that still only works with a pages repo? or can the repo then be called whatever it wants?

If I understand the current state of Codeberg pages, you can either have a repository with name pages, where its contents are just the static site files, or any repository with any name that has a pages branch, where the static files should be. I personally like just one repository for my website, which is why I was trying to get the second method (of a pages branch) working. I see many people doing the first way, where they have a deployment process where a source repository just force-pushes the statically built files to another repository, called pages.

> @adam where and how did you use the .gitignore file? I just have a [`.gitignore`](https://codeberg.org/adam/website/src/branch/main/.gitignore) file in the [`main` branch of my website repository](https://codeberg.org/adam/website/src/branch/main), and in that `.gitignore` file I have the `build` subdirectory added, which is the output directory for `hugo` (when running `hugo --destination build`). The shell script from my previous comment builds the whole site into this subdirectory by running `hugo --destination build`, so that none of the built files are checked into version control _of the `main` branch_ of the git repo. Then all of the static files are commited and force-pushed to the `pages` branch in the script. > you should also query which brench you are using and only use the master brench for creating the website, here is how i did it: > https://codeberg.org/Tealk/Git-Hooks_examples/src/branch/master/pre-push%20git%20hugo I just use one branch for my website source files, the `main` branch, so I haven't done any checks of what branch I'm in. I haven't tried your script, but from what I see it just commits and force-pushes the contents of the `public` subdirectory (which I assume is the output directory of `hugo` where the statically built site files are) _to the `master` branch_? Again, I'm not sure if I got that correctly, but then it wouldn't work with the current Codeberg pages setup, where the static files need to be in a `pages` branch of the repo. > but that still only works with a pages repo? or can the repo then be called whatever it wants? If I understand the current state of Codeberg pages, you can either have a _repository_ with name `pages`, where its contents are just the static site files, or any repository with any name that has a `pages` _branch_, where the static files should be. I personally like just one repository for my website, which is why I was trying to get the second method (of a `pages` branch) working. I see many people doing the first way, where they have a deployment process where a source repository just force-pushes the statically built files to _another_ repository, called `pages`.

Tealk commented 2022年02月22日 22:50:40 +01:00

@adam where and how did you use the .gitignore file?

I just have a .gitignore file in the main branch of my website repository, and in that .gitignore file I have the build subdirectory added, which is the output directory for hugo (when running hugo --destination build).

The shell script from my previous comment builds the whole site into this subdirectory by running hugo --destination build, so that none of the built files are checked into version control of the main branch of the git repo.

Then all of the static files are commited and force-pushed to the pages branch in the script.

i tried this several times but i always had the source files in the page branch. excluding the static folder from the commits is standard, isn't it?

I just use one branch for my website source files, the main branch, so I haven't done any checks of what branch I'm in.

so you develop and publish brench in master?

but from what I see it just commits and force-pushes the contents of the public subdirectory (which I assume is the output directory of hugo where the statically built site files are) to the master branch?

i develop in the develop brench in the pages-source repo -> if everything is to my satisfaction then i merge that into master and then the script works, it creates the hugo files (hugo automatically uses the public folder) and then pushes the changes directly into the pages repo in the master brench

or any repository with any name that has a pages branch, where the static files should be.

that would be interesting of course if it works like that

I see many people doing the first way, where they have a deployment process where a source repository just force-pushes the statically built files to another repository, called pages.

i think many do this because it is the way of git. having completely different files in a brench is like chaos in the order of git.

> > @adam where and how did you use the .gitignore file? > > I just have a [`.gitignore`](https://codeberg.org/adam/website/src/branch/main/.gitignore) file in the [`main` branch of my website repository](https://codeberg.org/adam/website/src/branch/main), and in that `.gitignore` file I have the `build` subdirectory added, which is the output directory for `hugo` (when running `hugo --destination build`). > > The shell script from my previous comment builds the whole site into this subdirectory by running `hugo --destination build`, so that none of the built files are checked into version control _of the `main` branch_ of the git repo. > > Then all of the static files are commited and force-pushed to the `pages` branch in the script. i tried this several times but i always had the source files in the page branch. excluding the static folder from the commits is standard, isn't it? > I just use one branch for my website source files, the main branch, so I haven't done any checks of what branch I'm in. so you develop and publish brench in master? > but from what I see it just commits and force-pushes the contents of the public subdirectory (which I assume is the output directory of hugo where the statically built site files are) to the master branch? i develop in the develop brench in the pages-source repo -> if everything is to my satisfaction then i merge that into master and then the script works, it creates the hugo files (hugo automatically uses the public folder) and then pushes the changes directly into the pages repo in the master brench > or any repository with any name that has a pages branch, where the static files should be. that would be interesting of course if it works like that > I see many people doing the first way, where they have a deployment process where a source repository just force-pushes the statically built files to another repository, called pages. i think many do this because it is the way of git. having completely different files in a brench is like chaos in the order of git.

adam commented 2022年02月22日 23:24:48 +01:00

i tried this several times but i always had the source files in the page branch. excluding the static folder from the commits is standard, isn't it?

Have you tried my script? It definitely commits just the static files to the pages branch, not the source files. You can see it here.

Yup, excluding the static folder from version control is standard — but looking back at the first comment of this issue — the original feature request was to have the static folder in version control and use that folder to host the website using Codeberg pages.

That is just like the other option of GitHub pages hosting, where GitHub takes the docs branch of any repo as a source of static files to host a GitHub pages website from. In that case there is just one branch (e.g. the main branch). An example of that is for example my GitHub pages website, deployed from the docs subdirectory which I generate by running hugo and having the outputDir set to it in config.toml (you could achieve the same by running hugo --destination docs. In my opinion this is not such a good workflow, as the other option of a separate branch and automated deployment, described below.

The second option is not commiting the static folder in the main branch, and just have the files in another branch, which GitHub pages or Codeberg pages takes as the branch from which to host the static files. On GitHub this is the gh-pages branch, and the whole process of generating the hugo static files to it and deploying is handled by a GitHub action, as seen here for example. On Codeberg, there is no CI "workflow" for this yet (although I think this could be a good use-case of Codeberg-CI, if possible, I might try it out, @fnetX) hence the shell script, which we're talking about, should aim to accomplish that.

so you develop and publish brench in master?

Yeah, this is just my little personal website, so I just commit directly to main, having a develop branch to merge into main after updating the README or the only page on my website would be a little overkill for me 😄.

i develop in the develop brench in the pages-source repo -> if everything is to my satisfaction then i merge that into master and then the script works, it creates the hugo files (hugo automatically uses the public folder) and then pushes the changes directly into the pages repo in the master brench

I see, so you're using the other approach — having two separate git repositories on codeberg — one with the source files, and the other called pages with the built files. Perfectly valid. It's just I prefer just one repository for everything. Although I quite like your approach of having it as a git-hook, and run automatically at each commit to my source!

i think many do this because it is the way of git. having completely different files in a brench is like chaos in the order of git.

Yup, I agree again, it's a little weird from a git point of view, but I'm just used to the GitHub action way of doing things I guess! 😊

> i tried this several times but i always had the source files in the page branch. excluding the static folder from the commits is standard, isn't it? Have you tried my script? It definitely commits just the static files to the `pages` branch, not the source files. You can see it [here](https://codeberg.org/adam/website/src/branch/pages). Yup, excluding the static folder from version control is standard — but looking back at the first comment of this issue — the original feature request was to have the static folder _in version control_ and use that folder to host the website using Codeberg pages. That is just like the other option of GitHub pages hosting, where GitHub takes the `docs` branch of any repo as a source of static files to host a GitHub pages website from. In that case there is just one branch (e.g. the `main` branch). An example of that is for example my [GitHub pages website](https://github.com/adam-sroka/website), deployed from the `docs` subdirectory which I generate by running `hugo` and having the `outputDir` set to it in `config.toml` (you could achieve the same by running `hugo --destination docs`. In my opinion this is not such a good workflow, as the other option of a separate branch and automated deployment, described below. The second option is not commiting the static folder in the `main` branch, and just have the files in another branch, which GitHub pages or Codeberg pages takes as the branch from which to host the static files. On GitHub this is the `gh-pages` branch, and the whole process of generating the hugo static files to it and deploying is handled by a GitHub action, as seen [here](https://github.com/jurkovicova/jurkovicova.github.io/commits/gh-pages) for example. On Codeberg, there is no CI "workflow" for this yet (although I think this could be a good use-case of Codeberg-CI, if possible, I might try it out, @fnetX) hence the shell script, which we're talking about, should aim to accomplish that. > so you develop and publish brench in master? Yeah, this is just my little personal website, so I just commit directly to `main`, having a `develop` branch to merge into `main` after updating the README or the only page on my website would be a little overkill for me 😄. > i develop in the develop brench in the pages-source repo -> if everything is to my satisfaction then i merge that into master and then the script works, it creates the hugo files (hugo automatically uses the public folder) and then pushes the changes directly into the pages repo in the master brench I see, so you're using the other approach — having two separate git repositories on codeberg — one with the source files, and the other called `pages` with the built files. Perfectly valid. It's just I prefer just one repository for everything. Although I quite like your approach of having it as a git-hook, and run automatically at each commit to my source! > i think many do this because it is the way of git. having completely different files in a brench is like chaos in the order of git. Yup, I agree again, it's a little weird from a git point of view, but I'm just used to the GitHub action way of doing things I guess! 😊

Tealk commented 2022年02月23日 14:02:18 +01:00

I have tested this now with mdbook and without the script sonden the commands manually entered but that should make no difference.

Here is the result:
https://codeberg.org/ButterflyAspect/mdBook/src/branch/pages

I have also adjusted my dns record:
grafik

at least it looks like it works

I have tested this now with mdbook and without the script sonden the commands manually entered but that should make no difference. Here is the result: https://codeberg.org/ButterflyAspect/mdBook/src/branch/pages I have also adjusted my dns record:  at least it looks like it works

Tealk commented 2022年02月23日 14:08:43 +01:00

why do you delete the output folder?

# delete previous site built, if it exists
if [ -d "$build_directory" ]; then
 echo "Found previous site build, deleting it"
 rm -rf $build_directory
fi

i have put this into a githook:
https://codeberg.org/Tealk/Git-Hooks_examples/src/branch/master/pre-push%20git-branch%20hugo

For your Script: Double quote to prevent globbing and word splitting: https://github.com/koalaman/shellcheck/wiki/SC2086

why do you delete the output folder? ``` # delete previous site built, if it exists if [ -d "$build_directory" ]; then echo "Found previous site build, deleting it" rm -rf $build_directory fi ``` i have put this into a githook: https://codeberg.org/Tealk/Git-Hooks_examples/src/branch/master/pre-push%20git-branch%20hugo For your Script: Double quote to prevent globbing and word splitting: https://github.com/koalaman/shellcheck/wiki/SC2086

adam commented 2022年02月23日 20:15:07 +01:00

why do you delete the output folder?

If the output folder is not empty at the beginning and contains some other files, then the script would commit them to the pages branch as well. This just ensures only the current hugo build is commited. I guess it could be removed if this is not gonna happen for you.

Lovely, I'll have a look at your GitHook and the suggestions for the script — I'm very new to bash scripting so thanks a lot! 😊

> why do you delete the output folder? If the output folder is not empty at the beginning and contains some other files, then the script would commit them to the `pages` branch as well. This just ensures only the current hugo build is commited. I guess it could be removed if this is not gonna happen for you. Lovely, I'll have a look at your GitHook and the suggestions for the script — I'm very new to bash scripting so thanks a lot! 😊

Tealk commented 2022年02月23日 20:40:03 +01:00

Lovely, I'll have a look at your GitHook and the suggestions for the script — I'm very new to bash scripting so thanks a lot! 😊

You can have your script checked here, for example: https://www.shellcheck.net/

> Lovely, I'll have a look at your GitHook and the suggestions for the script — I'm very new to bash scripting so thanks a lot! 😊 You can have your script checked here, for example: https://www.shellcheck.net/

Tealk commented 2022年02月24日 17:46:24 +01:00

So the scripts are now also tested and have brought my two pages online, ok currently only one runs but that's a DNS problem.

@momar what do you think? Would that have been your idea or how would you have imagined implementing it?

So the [scripts](https://codeberg.org/Tealk/Git-Hooks_examples) are now also tested and have brought my two pages online, ok currently only one runs but that's a DNS problem. @momar what do you think? Would that have been your idea or how would you have imagined implementing it?

6543 commented 2022年11月12日 22:15:24 +01:00

just use dedicated pages branch instead ...

just use dedicated `pages` branch instead ...