Site publishing from repository root even if base directory is set

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!

hi filo, looking at your repo:

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)

In that case, you can just leave the base directory blank, and set the publish directory to filippo.io

Can you try that and see if it works?
thanks.

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).

  1. don’t set a base directory.
  2. set publish directory of filippo.io
  3. set no build command
  4. ???
  5. profit.
1 Like

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 :slight_smile:

No worries, we are all doing our best with the world being how it is :slight_smile:

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?

The UI shows the wrong thing for some sites with odd configuration, yes. We know :slight_smile: Thanks for reporting though!

I think you’re saying you don’t have any problems that need attention still to get your sites working? Let me know if I’m wrong!

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/ :+1:
  • filippo.io + Base directory filippo.io + Publish directory not set = deploys from repo root :frowning:
  • 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. :slight_smile:

Thanks so much for the followup!

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: https://app.netlify.com/sites/dreamy-hawking-6b7da8/settings/deploys#build-image-selection), 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 :slight_smile:

(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.)

1 Like

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.

https://app.netlify.com/sites/dreamy-hawking-6b7da8/deploys/5f065e6ed33b670008b184ed

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.

This also broke my two other Netlify sites, which did not have a netlify.toml file.

https://app.netlify.com/sites/loving-poitras-2854c2/deploys/5f065e6e3974790007e840f4
https://app.netlify.com/sites/reverent-turing-84c38e/deploys/5f065e6ebedc240007f50946

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!