One codebase, two different deployment results?

Hi @fool

I think you’ve misunderstood the situation. I’ve mentioned this 3 or 4 times now in the thread, but to clarify again…

There are two Netlify sites:
Site A - chorus-app.netlify.app. This is the site in Michael Pumo’s Netlify account which is working as expected
Site B - choruslondon.netlify.app. This is the site in Chorus London’s Netlify account which is not working as expected

There are two GitHub repo links we’ve been discussing:
GitHub A - github/michaelpumo/Chorus. This is the repo from which Site A is built.
GitHub B - github/ChorusAgency/Chorus. This is the repo from which Site B is built.

The point I’ve made numerous times in this thread, which doesn’t appear to be acknowledged/believed by you or your colleagues, is that GitHub A is the same repo as GitHub B.

But why are there two different links?

Michael developed the site for us initially. As a result, it was built and pushed to his own GitHub account, github/michaelpumo. Michael also set up the hosting of the site on Netlify while the repo was still under his own GitHub account. This is why when you go into Michael’s dashboard and look at Site A, you see the current repository as this link - github/michaelpumo/Chorus.

After Michael finished with the project, he transferred the GitHub repo from his own account, to our account, github/ChorusAgency. When he did that, the repo moved from github/michaelpumo/Chorus to github/ChorusAgency/Chorus.

Want proof? You guys can’t see this since the repo is private, but I recorded a screencast proving that visiting the url for GitHub A results in a redirect to GitHub B. See the Loom video linked in this post - One codebase, two different deployment results? - #7 by ChorusAgency.

The reason this redirect is happening is because it’s the same repo, just with a new url because it was moved. Even though the url is different, the repo is the same.

You mentioned that one of the sites has 98 vs 99 files. There’s a reason for this…

We have a webhook from our headless CMS (Prismic) set up on Site B. We do not have a webhook for our headless CMS set up on Site A. What this means is, if there is a change to the content in Prismic, Site B is automatically rebuilt with the changed Prismic content incorporated. Site A is not automatically rebuilt.

Could this be the cause of the issue then? No. The issue was still there last time we pushed a change to the GitHub repo, which in turn caused Netlify to rebuild both Site A and Site B. This put the content in a state of exact alignment, but the problem was still there.

As I’m sure you can understand, there’s been 23 days since this topic was first opened, so of course there have been changes in the Prismic repo. I can push a change to the GitHub repo to align the content of Site A and Site B again if you want, just to prove the point to you that this is not the source of the issue?

So given the above points, the assertion that you’re making (which is that they’re different codebases, and this explains the difference in behaviour) is entirely wrong.

Given all of the above, I still don’t see this issue as resolved as you continue to insinuate that the difference between Site A and Site B is caused by differences in the codebase, which it’s patently not. I thought @luke may have been along the right lines when he pointed out that there were differences in the Netlify settings between Site A and Site B (specifically the build image), but aligning the build images didn’t fix the issue.

Again, I cannot understand how two sites being built from an identical codebase can be having different outcomes here, and no one else seems to be able to offer a proper explanation for it.

This issue is now over 3 weeks old, is there any way to escalate it? I don’t think dealing with multiple people is helping as whenever someone new responds they don’t seem to have read and fully understood the context of the issue.

For some reason, the loom link in the previous post appears to have been flagged? Here’s the link - Loom | Free Screen & Video Recording Software | Loom

Could this please be investigated as a matter of urgency? A further 9 days have now passed with no response. It’s over a month since the thread was initially opened now

@ChorusAgency As Netlify have indicated diplomatically a few times, it’s unfortunately not really their place to debug your project, as they’re primarily a “self-service hosting environment”.

As @fool mentioned, it can look like the difference only occurs on Netlify, but it’s significantly more likely that there is a difference in the installation/execution of the codebase, or the configuration, than it is an actual “Netlify problem” that their staff would need to assist you with.

If you’re able to provide access to your repository, even privately, then I can take a look and see if I can spot what’s going on.

Hi @nathanmartin

I still don’t understand how the problem could lie anywhere other than Netlify though. If the exact same codebase is being used, presumably the only difference in the entire stack could be the way Netlify is deploying the site in each instance?

Hey there, @ChorusAgency :wave:

We acknowledge that you are seeing different things between the two sites-- I do not believe that we have misunderstood this. Unfortunately, debugging the specific code between the two sites is beyond the scope of support, which I am linking here: Netlify Scope of Support.

To double check that we believe this is code based, we took a quick look at the repos, and one difference is that you are using different functions directories. While this may not be causing two entirely different views, I do believe it is evidence that there may be more repo based differences that you can look into. Here are links where you can see this:

Site A Functions (default) - Netlify App
Site B (customized, sym) - Netlify App

Additionally, here are a few more resources for your debugging process:
Assuming you forked the original repo, so here’s a doc on how to compare forks: Comparing commits - GitHub Docs

Here is documentation on how to compare commits (you can compare the 1st copy of the original codebase and any changes that have been made): Comparing commits - GitHub Docs

Lastly, here is documentation on how to view differences between commit views (you may not be seeing everything that’s changed depending on your view) - Differences between commit views - GitHub Docs

Again, further debugging of your code is outside the scope of our Support. I know this is not the news you are looking for, and I hope that the above information is enough to get you on the right track.

I don’t think it matters too much.

Surely the most important thing is just that you get the new copy of the site operating how you want?

@hillary

You’re saying “Assuming you forked the repo”. Did you miss/ignore the previous posts where I explained that both sites use the same repo multiple times? If the repos are not the same, how come one repo url redirects to another? Video evidence here - Loom | Free Screen & Video Recording Software | Loom

There are three scenarios where a GitHub repo would be redirected (according to GitHub - source):

  • When you rename a repository.
  • When you rename your user or organization account.
  • When you transfer a repository from one user or organization to another.

Note that none of these answers is “When your repository is forked”. I have provided video evidence that the url is redirecting, which is therefore irrefutable evidence that the repo is not forked and that it’s the same repo, yet you continue to question this.

I believe there is an effort here to try and discredit what I am saying in order to be able to say “further debugging of your code is outside the scope of our Support” and therefore avoid having to dig into the issue deeper and provide actual support.

A direct question that I’d like you to answer please - If the repo is indeed the same, do you accept that the issue lies with how the Netlify platform is deploying the two sites differently?

You said that “one difference is that you are using different functions directories”. A couple of issues with this:

  • I only have access to ‘Site B’, but from what I can see on my end, there is not a custom directory. The ./functions directory is being used
  • There are no serverless functions in this repository, therefore surely any difference in how the functions directory is set up is a reflection on Netlify’s defauly configuration and indicates that the Netlify platform is handling the sites differently and potentially causing this issue?

@nathanmartin

I think it matters a lot.

The same codebase is being used for both sites. One site is working as intended, the other is not. How could it be a code issue that needs debugging when it is working as intended on one of the Netlify builds?

All I’m asking is for Netlify to deploy the site in the exact same way in both instances, but for some reason their platform is deploying differently for the same identical codebase.

@ChrousAgency What matters most is “how it builds”, which is to say that if you can get it to build correctly locally, and confirm the configuration required, then you can easily replicate that to build it correctly remotely.

Netlify don’t manage the site instances for customers, (presumably unless you’re on an enterprise plan), so since you’re likely self-service then it’s up to you (or your developer/s) to know what configuration your codebase requires and to understand why it executes the way that it does.

My offer stands, I’m a developer and long time Netlify user.
I might be able to help, I might not, but either way I wouldn’t charge you.
I’m just interested in finding out what’s ultimately going on and can see you’ve been struggling with this for some time.

I’ve narrowed down the difference to be a trailing-slash issue. For example, if you visit:

https://chorus-app.netlify.app/projects/

you can see, the videos don’t load.

But if you visit:

https://chorus-app.netlify.app/projects

They do load.

I’m assuming, same would be happening with:

https://choruslondon.netlify.app/projects

But sadly, that page gets 301 redirected to:

https://choruslondon.netlify.app/projects/

and I’m trying to determine what’s causing the redirect.

2 Likes

Hi @hrishikesh

Thanks very much for looking at this!

You’re right, the trailing slash seems to be correlated with the videos not loading. I hadn’t noticed that before!

on https://choruslondon.netlify.app/projects/, when you click to another page and then click back to the projects page, the trailing slash disappears and the videos work.

It’s strange that the page would render differently based on having (or not having) a trailing slash.

A wild guess at the underlying problem would be that the page code is triggering based on the path/route and only initializing the slider when it is precisely projects. In the case of the trailing slash it may be receiving projects/ and not triggering.

If you can get the redirects/routing directing the user to the right path then it should seemingly all just work.

1 Like

While what @nathanmartin said is true and fixing the underlying cause of the videos not working with trailing vs non-trailing would be a better solution, I’m not sure if that’s possible with your setup.

I checked further and it appears that, on the choruslondon site, we’re treating /projects/ as a canonical path and redirecting to that. On the chorus-app website, this is not happening, and while I’m not sure about the reason, I believe it’s because that site has a custom domain. When a site has custom domain, we add a link: rel="canonical" tag automatically. Chances are, this would be preventing the redirect.

You can confirm this behaviour, by visiting https://chorus.london/projects, which again gets redirected to https://chorus.london/projects/. Now this is the domain set on chorus-app site - the one that’s “working fine”. When serving the site on the custom domain, we don’t apply that link header. This is possibly why, we’re redirecting it.

My bad, I tried the wrong URL, the custom domain on the other site is not getting redirected too. However, the following is still worth a try:

So, the solution? You could try adding, a link: rel="canonical" header to your sites to see if it works. The header could look like:

link: <https://chorus-london.netlify.app/projects>; rel="canonical"
2 Likes

Hi @hrishikesh

Thanks for confirming. While you were investigating this further, I was too and I found this link: Redirect options | Netlify Docs

I’d hoped that by turning this on it would fix the issue, but it didn’t seem to work.

I’ve updated the website to now have the canonical tag you recommended but the issue still appears to be there.

Since it seem that the only difference between the two sites is the fact that one has a custom domain and the other doesn’t, this may well be the cause of the problem. The only thing is, we don’t want to risk transferring the domain over to our new site then losing the working version if this is not the source of the issue.

Could there be any other differences in the Netlify control panel settings that are related to this?

Hi @hrishikesh

Is there anything else we could try changing here to align the two sites in the way they deal with the trailing slash?

I can make some changes to the code if you think there is a solution there, but I think it would be ideal if we could identify what the difference in the Netlify config/settings is that is causing this and fix that?

Thanks

Hi @ChorusAgency,

We’ve escalated this to our engineers to see why just one of the sites is having that redirect and not the other, and also to ask if there are any available workarounds. We’ll keep you posted as we hear from them.

1 Like

Hi @hrishikesh

Thanks so much for this! Just wondering if you’ve heard back from your engineers?

Hey @ChorusAgency,

Sorry for the delay. Apparently, this week’s meeting with the engineers was preponed due to some events. So, the issue that I filed for them to look at was filed after that. There would be another meeting in the coming week where I believe this would be discussed.

Hey @ChorusAgency,

It appears that you’ve Pretty URLs turned on that’s causing the redirect. Would you be able to disable that and see if that fixes it?

1 Like