Hello, I think I encountered a bug in the base directory implementation.
My site dreamy-hawking-6b7da8 deploys from a repository where the site files are in “filippo.io/”. I set the base directory as “filippo.io”, and that should have been enough to make the setup work. I have other sites set up like that from that very same repository.
Instead, the deploy published the repository root and caused downtime.
I had to set the publish directory to filippo.io/filippo.io (which does not exist) for it to work.
No idea what’s different about this site, but I did switch linked repository, so maybe that’s how it entered a broken state.
hi, welcome! could you share a screenshot of your current build settings? that might be helpful to figure out whether this is expected behaviour or a bug. Thanks!
it looks like you aren’t using a static site generator but instead are simply asking the platform to publish your pre-existing html files, which is consistent with why you don’t have a build command.
(here is an example of different project of ours that is set up this way)
That wouldn’t work because it wouldn’t find the _redirects file in filippo.io/ and anyway this is pretty clearly a bug I’m trying to report. No reason to think it doesn’t affect other users that do use a build command, and until I worked around it it took the site down.
I know this is the same advice that Perry gave you, but you should follow it, and does work - I just forked your repo and tested and all headers and redirects in the filippo.io/ subdirectory were processed (1 and 37 respectively).
Ah, looks like I’m wrong about where _redirects is read from then, but again, my site works, I don’t need another workaround. (Also, I like that the site is not redeployed when there are no changes inside the base directory, isn’t that what the feature is also for?) I was trying to help by reporting a bug, which probably is not specific about my site.
Here is another site that is deployed from the same repository with the same directory structure. filippo.io is clearly in a bad state, and if I configure it like mkcert.dev, it breaks.
If you disagree that it’s a bug I’d be happy to provide logs or learn that I’m missing something. If you don’t care about the bug that’s also ok, feel free to close this.
hi again, sorry to be slow to get back to you - looking at the contents of mkcert.dev folder in that repo, I see no content that we could deploy - just a _headers and _redirects files. I’m not quite sure what you were expecting was going to happen, so at the moment we are still trying to confirm whether this is expected or a bug
No worries, we are all doing our best with the world being how it is
I don’t see how the lack of content makes any difference, as indeed the _redirects file gets deployed.
Notice the difference: mkcert.dev without a publish directory takes the _redirects file (and the content if there was any) from mkcert.dev/, while filippo.io without a publish directory looks for _redirects (and content) in the repo root, even if both have a similar base directory set.
Besides, in my first screenshor you can see that the Publish directory is rendered as filippo.io/filippo.io. I think you’ll agree that directory doesn’t exist, so surely this is a bug?
It’s not just a UI issue. filippo.io behaves differently from mkcert.dev, and that did cause me downtime before I worked around it. They are not supposed to have different configuration.
mkcert.dev + Base directory mkcert.dev + Publish directory not set = deploys from mkcert.dev/
filippo.io + Base directory filippo.io + Publish directory not set = deploys from repo root
filippo.io + Base directory filippo.io + Publish directory filippo.io/filippo.io = deploys from filippo.io/
I’ve run out of ways to explain it, so at this point I think I did what I could to report the bug, and it’s up to you if you want to investigate.
I think I can see why by the way - filippo.io is using our legacy “trusty” build image; I think if you update to xenial (here: Netlify App), then things will work as you expect. However, there are substantial updates to the build environment if you do that, so if you have a solution that works well enough for you, you might consider sticking with the current setup rather than “porting” your build to newer software.
Indeed, switching to Xenial and unsetting the Publish directory works as expected! Looks like this is a bug in how Base directories are handled with the Trusty image. Nice catch
(Closing this because I think you’ve got all the info you need to reproduce this, but let me know if you need me to test anything.)
FYI, this broke again. I did not change anything about my site (Xenial, no publish directory set anywhere, base directory set in the UI) and doing a git push took down everything.
Somehow figured out a workaround by setting publish = "." in the netlify.toml.
Up to you if you want to investigate, I am pretty disappointed but don’t have the resources to dedicate to debugging this, I’m afraid.
Thanks for the reports and sorry for the new trouble!
After spending 20 minutes trying to understand what happened there, I am still not sure what was going on there exactly. However, my goal would have been getting you to where you are; glad you managed to find a solution that works for you!
