Any progress on this?

I'll try to reproduce this week. Unfortunately, I think the only way to debug what's going on is to deploy to production and then roll back.

Jon: when testing this locally and on the staging server, did you use a production build? (You probably did, but I figured I'd ask anyways.)

John wrote:

... way to debug what's going on is to deploy to production and then roll back.

• We could tweak the build scripts to deploy a PR build to a staging server so that you could test w/o touching the production server.

  For the past couple of months we've been witnessing significant differences in behavior between Travis (Linux) vs macOS site builds. It occurred to me that it might be worth testing whether this is the cause of the difference in inject script behavior too. That is, that the difference in behavior might not be due to the choice of server (or whether we're testing a dev vs. production build), but rather that the site is being built on Travis and deployed from there -- i.e., built under a Linux environment.

• Another thing to try would be to build and test the site locally under Linux (the same flavour as the one Travis uses).

cc @kwalrath

@chalin

Jon: when testing this locally and on the staging server, did you use a production build?

I followed the steps in https://github.com/flutter/website#deploy-to-a-staging-site, not sure if that's what you mean by "production build".

Do build a production version of the site you need to set the following environment variable: JEKYLL_ENV=production, like we do on Travis,

I usually do something like this:

$ rm -Rf _site/*; JEKYLL_ENV=production ./tool/serve.sh

That will build and serve (locally) a clean production-version of the site. Then you can deploy using the deploy script.

Hey all, I've got #3313 open which depends on this functionality. I've followed @chalin's instructions to deploy a production version to my own staging and I'm not seeing this issue (at the bottom of the page): https://brianegan-flutter-staging.firebaseapp.com/docs/cookbook/animation/page-route-animation

Not sure if that's helpful, but this would definitely be a blocker on that work so wanted to chime in and see if I could help at all!

• This is from a Mac running OSX Catalina, not a linux build

I'm going to check to see if there's a time today when folks won't mind if we test this in production (not just the production build described above, but the actual flutter.dev site). Will keep this issue updated.

It looks like the production build is stripping out certain files. Here's two pages when when deployed to firebase and to production:

firebase_vs_production.zip

The production version was missing certain JS assets, including diff2html

Hey all -- wanted to say I've run into one other interesting problem with using iframe embeds + gists instead of keeping the code inside the flutter/website and dart/site-www repos: Github Rate limits.

If you refresh a page or move from one page to another and make over 10 or so API calls to github to load the associated gists, you'll run into rate limiting like so:

I can see this has a P3-Low, but this issue is a bit of a blocker on the codelabs work I'm doing & changes to the flutter cookbook. Any possibility it could get a bit more attention/higher prio?

Overall, I think keeping this code in gists vs keeping the code in the repo not only affects the quality of each codebase (gists are not checked with dart analyzer, code snippets are; no git history of the changes; etc), but it now looks as though this issue will effect users if we keep going down the embedded gist route and adding more of these to different pages.

@brianegan thanks for pointing out the rate limits issue -- I've definitely run into this a lot while putting codelabs together. I don't know if this will help you at all, but one thing I've done to avoid the issue is to comment out any/all embeds that I'm not working on to limit the number of calls to the GitHub API.

Thanks for bumping this all. I'll bump the label priority on the issue to reflect the urgency here -- however, I don't think we will have cycles to investigate this further until ~12/16. Please let me know if you still have any concerns.

Thanks so much, @legalcodes!

Just curious: has anyone seen this problem anywhere else, i.e., other than on flutter.dev?

Maybe we could deploy a simple test page (that we exclude from the sitemap) on site-www to see if the problem manifests itself there too, or whether it is specific to this website. @kwalrath, et all, WDYT? (Btw, at some point at least one of our sites used to have such a "site-developer playground page", but it seems that we've removed it.)

I haven't seen it on dart.dev.

I'd really like to see this issue resolved. I've read through it a couple of times. One thing I did notice when John mentioned diff2html: I recently saw a lot of "diff2html" errors being reported when running tool/serve.sh. It turns out it was because I hadn't run the before_install and install scripts on my brand new repo. (I had sourced the environment variable file.)

Probably not related, but thought I'd mention it.

@sfshaza2 I've chatted with @RedBrogdon about this, I think we can look to him and @johnpryan for updates.

Good news everyone,

It seems like when Jekyll runs on Travis, it can't parse front-matter with JSON in it. this change fixed the issue.

Bad:

js: [{defer: true, url: https://dartpad.dev/experimental/inject_embed.dart.js}, {defer: true, url: /assets/codelabs/js/animations_examples.js}]

Good:

js: 
  - defer: true
    url: https://dartpad.dev/experimental/inject_embed.dart.js
  - defer: true
    url: /assets/codelabs/js/animations_examples.js

My understanding is that Jekyll front-matter is YAML, and YAML is a superset of JSON. So it's technically OK to put [{key: "value"}] (it works on all of our macs), but there's something different about Travis that causes it to fail. We could do some more testing on Linux and figure out why, but it's probably safer to use YAML everywhere (at least for now.)