Track Firebase hosting migration #16417
Comments
|
@petebacondarwin thank you! |
|
@Narretz is it correct that the timeout issue is resolved? |
|
@IgorMinar yes the issue is resolved. It was an encoding issue not a file size issue. The zip files were additional gzipped for faster upload but this confused gcs / Firebase. I replaced all the available zips with their default form and now it works. The deployment has been updated too |
|
So I guess that means that we are good to go then. Right? I book Wed 9-10am PT on my calendar to make this go live + sent out an invite to you two. |
|
@petebacondarwin what about blog.angularjs.org? have you thought about it? if we don't change anything, I believe that it will break because of the certs and the current proxy setup. I think we'll need to do something like: |
|
@IgorMinar - yes we need to setup the DNS to CNAME to point to blogger and then set up the blog on Blogger to accept incoming connections from that domain - I believe there is now a setting that allows HTTPS. I don't have admin rights to do either of these two. The alternative is to change blog.angularjs.org to point directly to blog.angular.io, which is not hosted on blogger but something else... |
|
I was thinking about this more and I think the lowest risk will be to just setup a redirect from blog.angularjs.org to blogger. The current DNS setup is messed up anyway and most urls on the web point to either |
|
@IgorMinar that would be fine by me but I think it will need, yet another, Firebase project setup for the subdomain, right? |
|
all but ci.angularjs.org are switched now. @petebacondarwin we need to decide what to do with the jenkins instance. without the global proxy we no longer have a signed certificate for it. Could you look into getting a cert from lets encrypt and installing it on the box? |
|
haha.. so much for "we need to decide". above is my proposal. the only two alternatives is to use a self-signed cert (bad ux) or switch to http (bad security). @petebacondarwin if there are other options please propose them. |
|
Can we continue to use the IP address directly for Jenkins, @IgorMinar? |
|
@petebacondarwin we can. but that's far from ideal :) I update the DNS to point to the new ip address which uses self-signed cert. You can only bypass the cert if you visit the domain with a browser that previously hasn't visited the site because of angularjs.org previously serving So we'll either fix the cert or wait half a year for us to be able to bypass the cert warning. If you don't care, we can just document this and move on... |
|
I updated the hosting doc. let's move on.. :) |
@petebacondarwin was this referring to dashboard.angularjs.org or something else? |
|
@IgorMinar - I was referring to setting up a "redirect" from blog.angularjs.org to blogger. A HTTP redirect (rather than a DNS based solution) would require a configured server. |
I don't care :-) |
|
On Thu, Jan 25, 2018 at 11:57 PM Pete Bacon Darwin ***@***.***> wrote:
@IgorMinar <https://github.com/igorminar> - I was referring to setting up
a "redirect" from blog.angularjs.org to blogger. A HTTP redirect (rather
than a DNS based solution) would require a configured server.
I see. This turned out not to be necessary. Blogger now has support for
vanity urls and https so it all worked out.
|
|
I have disabled the following jobs on ci.angularjs.org:
|
|
Something that's not in the list is that we are no longer publishing the build artefacts to the code.angularjs.org github repository, since we deploy to Firebase directly to Travis. I mentioned this before, but I just wanted to make sure that we are on the same page about this. |
|
there issues with code.angularjs.org robots.txt: The following urls/patterns are not configured correctly:
|
|
I updated the checklist above with the summary of new issues that need followup. |
|
|
I've copied the sitemap generation script from angular.io, and it looks good. I just need to filter out the example files. |
|
I don't think we want to index any of code.angularjs.org |
|
Yeah, I realized versions-data.js is needed because it is loaded by docs.angularjs.org, so that it always has the most up to date list of versions. |
|
yup. you got it. sorry about forgetting to mention the reason - indeed the
file with version number is being loaded across the domains from
docs.angularjs.org and that's why it needs to be allowed.
…On Mon, Feb 5, 2018 at 3:25 AM Martin Staffa ***@***.***> wrote:
Yeah, I realized versions-data.js is needed because it is loaded by
docs.angularjs.org, so that it always has the most up to date list of
versions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16417 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANM6KobUbhFX0agp3h2-NgJkJk9f6evks5tRuUsgaJpZM4RlWE3>
.
|
|
The robots.txt at code and docs have been updated: Sitemap has been added to docs: |
|
are we sure that disallowing /partials/ and /img/ in docs.angularjs.org is
the right thing to do?
keep in mind that for google to be able to crawl docs.angularjs.org it
needs to be able to access all resources via both the non-js crawler (this
is why I'm concerned about /partials/) and js-crawler (this is why I'm
concerned about /img/).
all of this stuff is black magic as far as I'm concerned, so I don't know
for sure if these concerns are valid or not. we'll need to test this in
prod to see the results.
…On Mon, Feb 5, 2018 at 1:37 PM Martin Staffa ***@***.***> wrote:
The robots.txt at code and docs have been updated:
https://docs.angularjs.org/robots.txt
https://code.angularjs.org/robots.txt
Sitemap has been added to docs:
https://docs.angularjs.org/sitemap.xml
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16417 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANM6CBbo4I281pjAm8b0qVdBwNVZYXJks5tR3SugaJpZM4RlWE3>
.
|
|
If we allow the partials then they become indexed, which means that the raw partial is visible in searches. I don't think it matters what we do with images - we should probably allow them so that people can search for images in the guides. |
This commit restores serving the plain partials (content) when a docs page is accessed with ?_escaped_fragment_=. The Google Ajax Crawler accesses these urls when the page has `<meta type="fragment" content="!">` is set. During the migration to Firebase, this was lost, which resulted in Google dropping the docs almost completely from the index. We are using a Firebase cloud function to serve the partials. Since we cannot access the static hosted files from the function, we have to deploy them as part of the function directory instead, from which they can be read. Related to angular#16432 Related to angular#16417
This commit restores serving the plain partials (content) when a docs page is accessed with ?_escaped_fragment_=. The Google Ajax Crawler accesses these urls when the page has `<meta type="fragment" content="!">` is set. During the migration to Firebase, this was lost, which resulted in Google dropping the docs almost completely from the index. We are using a Firebase cloud function to serve the partials. Since we cannot access the static hosted files from the function, we have to deploy them as part of the function directory instead, from which they can be read. Related to angular#16432 Related to angular#16417
This commit restores serving the plain partials (content) when a docs page is accessed with ?_escaped_fragment_=. The Google Ajax Crawler accesses these urls when the page has `<meta type="fragment" content="!">` is set. During the migration to Firebase, this was lost, which resulted in Google dropping the docs almost completely from the index. We are using a Firebase cloud function to serve the partials. Since we cannot access the static hosted files from the function, we have to deploy them as part of the function directory instead, from which they can be read. Related to angular#16432 Related to angular#16417
This commit restores serving the plain partials (content) when a docs page is accessed with ?_escaped_fragment_=. The Google Ajax Crawler accesses these urls when the page has `<meta type="fragment" content="!">` is set. During the migration to Firebase, this was lost, which resulted in Google dropping the docs almost completely from the index. We are using a Firebase cloud function to serve the partials. Since we cannot access the static hosted files from the function, we have to deploy them as part of the function directory instead, from which they can be read. Related to angular#16432 Related to angular#16417
This commit restores serving the plain partials (content) when a docs page is accessed with ?_escaped_fragment_=. The Google Ajax Crawler accesses these urls when the page has `<meta type="fragment" content="!">` is set. During the migration to Firebase, this was lost, which resulted in Google dropping the docs almost completely from the index. We are using a Firebase cloud function to serve the partials. Since we cannot access the static hosted files from the function, we have to deploy them as part of the function directory instead, from which they can be read. Related to angular#16432 Related to angular#16417
This commit restores serving the plain partials (content) when a docs page is accessed with ?_escaped_fragment_=. The Google Ajax Crawler accesses these urls when the page has `<meta type="fragment" content="!">` is set. During the migration to Firebase, this was lost, which resulted in Google dropping the docs almost completely from the index. We are using a Firebase cloud function to serve the partials. Since we cannot access the static hosted files from the function, we have to deploy them as part of the function directory instead, from which they can be read. Related to angular#16432 Related to angular#16417
This commit restores serving the plain partials (content) when a docs page is accessed with ?_escaped_fragment_=. The Google Ajax Crawler accesses these urls when the page has `<meta type="fragment" content="!">` is set. During the migration to Firebase, this was lost, which resulted in Google dropping the docs almost completely from the index. We are using a Firebase cloud function to serve the partials. Since we cannot access the static hosted files from the function, we have to deploy them as part of the function directory instead, from which they can be read. Related to #16432 Related to #16417
This commit restores serving the plain partials (content) when a docs page is accessed with ?_escaped_fragment_=. The Google Ajax Crawler accesses these urls when the page has `<meta type="fragment" content="!">` is set. During the migration to Firebase, this was lost, which resulted in Google dropping the docs almost completely from the index. We are using a Firebase cloud function to serve the partials. Since we cannot access the static hosted files from the function, we have to deploy them as part of the function directory instead, from which they can be read. Related to #16432 Related to #16417
The text was updated successfully, but these errors were encountered: