You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
deploy creates a directory with the version number, something like 0.1.0, and puts the html there. If you run deploy twice without changing the version number it will print a warning:
Warning: './0.1.0' already exists. Use force to overwrite it.
and then deploy will create another directory 0.1.0 inside the already existing 0.1.0 directory.
The result looks like this:
0.1.0
0.1.0
docs
... other stuff
docs
... other stuff
The doc says that deploy(...;force=true) will overwrite the existing 0.1.0 directory but when I've tried this it does not overwrite the existing directory. It still writes the new 0.1.0 subdirectory inside the existing one and then crashes with this error:
If the top 0.1.0 directory is removed then deploy works again.
This overall behavior was confusing to me and is one of the things that has caused github deployment not to work. @MichaelHatherly perhaps I'm not understanding the logic of how deploy is supposed to be used and under what circumstances someone would want the default to be this nesting directory behavior. Is this a bug or is it intentional and I'm just not getting it? If it is intentional maybe more explanation in the docs would be helpful? If you explain it to me I'll write the documentation.
The text was updated successfully, but these errors were encountered:
deploy creates a directory with the version number, something like 0.1.0, and puts the html there. If you run deploy twice without changing the version number it will print a warning:
and then deploy will create another directory 0.1.0 inside the already existing 0.1.0 directory.
The result looks like this:
0.1.0
0.1.0
docs
... other stuff
docs
... other stuff
The doc says that deploy(...;force=true) will overwrite the existing 0.1.0 directory but when I've tried this it does not overwrite the existing directory. It still writes the new 0.1.0 subdirectory inside the existing one and then crashes with this error:
If the top 0.1.0 directory is removed then deploy works again.
This overall behavior was confusing to me and is one of the things that has caused github deployment not to work. @MichaelHatherly perhaps I'm not understanding the logic of how deploy is supposed to be used and under what circumstances someone would want the default to be this nesting directory behavior. Is this a bug or is it intentional and I'm just not getting it? If it is intentional maybe more explanation in the docs would be helpful? If you explain it to me I'll write the documentation.
The text was updated successfully, but these errors were encountered: