Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cleanDestinationDir in the config file is ignored sometimes #8433

Open
Kzer-Za opened this issue Apr 18, 2021 · 4 comments
Open

cleanDestinationDir in the config file is ignored sometimes #8433

Kzer-Za opened this issue Apr 18, 2021 · 4 comments
Labels
Milestone

Comments

@Kzer-Za
Copy link

Kzer-Za commented Apr 18, 2021

hugo v0.81.0+extended linux/amd64 BuildDate=unknown

Specifically, it seems to be ignored if you have never used this option from CLI. After installing Hugo I just put cleanDestinationDir: true in config.yaml of the site I'm trying to make. However, the command hugo never deleted any directories or files that were becoming obsolete. For example, I first built the site with the default taxonomies, but later decided that I didn't need them, so I disabled them with

disableKinds:
- taxonomy
- term

However, after running hugo the directories "tags" and "categories" were still in "public". The same was the case with obsolete files/directories in "content". Only after I have commented the option cleanDestinationDir: true in the config.yaml and ran hugo --cleanDestinationDir from the command line did Hugo build the "public" directory without the obsolete files/directories.

After that, to test the issue, I uncommented the line in the config and ran just hugo. But now the option in config is working and the obsolete files are deleted from "public" as they should. It's like something has been initialized by running hugo --cleanDestinationDir once.

@matt9189
Copy link

I am unable to reproduce this error. When I create a new site and run hugo with the default config, it creates the two folders. When I modify the config file with the following:
disableKinds = ["taxonomy", "term"]
cleanDestinationDir = true
It removes the two folders from the public folder as expected.

@jmooring
Copy link
Member

jmooring commented Apr 20, 2021

I can reproduce the problem.

TLDR --cleanDestinationDir fails to remove items from the public directory unless the static directory is present.

hugo new site mysite
cd mysite
hugo
find . -type d -name categories -o -name tags

The categories and tags directories are present (PASS).

hugo --disableKinds "taxonomy,term" --cleanDestinationDir
find . -type d -name categories -o -name tags

The categories and tags directories are gone (PASS).

hugo
find . -type d -name categories -o -name tags

The categories and tags directories are present (PASS).

rmdir static
hugo --disableKinds "taxonomy,term" --cleanDestinationDir
find . -type d -name categories -o -name tags

The categories and tags directories are still present (FAIL).

mkdir static
hugo --disableKinds "taxonomy,term" --cleanDestinationDir
find . -type d -name categories -o -name tags

The categories and tags directories are gone (PASS).

This may not be the only way to trigger the problem.

@jmooring jmooring added the Bug label Apr 20, 2021
@bep
Copy link
Member

bep commented Apr 21, 2021

So, this get skipped if there are no static directories.

I suggest that we in that case just do a "walk and Remove" in the DestionationFs -- but we need to respect the filter that we apply in the normal case:

syncer.DeleteFilter = func(f os.FileInfo) bool {

@ResamVi
Copy link
Contributor

ResamVi commented May 20, 2021

With the help of @jmooring's string of commands and with respect to what @bep mentioned I made the pull request that atleast fixes that kind failure we observed right now

@bep bep modified the milestones: v0.84, v0.85 Jun 18, 2021
@bep bep modified the milestones: v0.85, v0.86 Jul 5, 2021
@bep bep modified the milestones: v0.86, v0.87, v0.88 Jul 26, 2021
@bep bep modified the milestones: v0.88, v0.89 Sep 2, 2021
@bep bep modified the milestones: v0.89, v0.90 Nov 2, 2021
@bep bep modified the milestones: v0.90, v0.91.0 Dec 13, 2021
@bep bep modified the milestones: v0.91.0, v0.92.0 Dec 22, 2021
@bep bep modified the milestones: v0.92.0, v0.93.0 Jan 12, 2022
@bep bep modified the milestones: v0.93.0, v0.94.0 Mar 1, 2022
@bep bep removed this from the v0.94.0 milestone Mar 9, 2022
@bep bep added this to the v0.115.0 milestone Jun 13, 2023
@bep bep modified the milestones: v0.115.0, v0.116.0 Jun 30, 2023
@bep bep modified the milestones: v0.116.0, v0.117.0 Aug 1, 2023
@bep bep modified the milestones: v0.117.0, v0.118.0 Aug 30, 2023
@bep bep modified the milestones: v0.118.0, v0.119.0 Sep 15, 2023
@bep bep modified the milestones: v0.119.0, v0.120.0 Oct 4, 2023
@bep bep modified the milestones: v0.120.0, v0.121.0 Oct 31, 2023
@bep bep modified the milestones: v0.121.0, v0.122.0 Dec 6, 2023
@jmooring jmooring mentioned this issue Jan 4, 2024
@bep bep modified the milestones: v0.122.0, v0.123.0, v0.124.0 Jan 27, 2024
@bep bep modified the milestones: v0.124.0, v0.125.0 Mar 4, 2024
@bep bep modified the milestones: v0.125.0, v0.126.0 Apr 23, 2024
@bep bep modified the milestones: v0.126.0, v0.127.0 May 15, 2024
@bep bep modified the milestones: v0.127.0, v0.128.0 Jun 8, 2024
@bep bep modified the milestones: v0.128.0, v0.129.0 Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants