Site is not publishing to GitHub Pages

[brian-rose]

As discussed in https://github.com/ProjectPythia/projectpythia.github.io/pull/328, there is something wrong with the actions that take the rendered site and publish it on GitHub Pages so it's visible at https://projectpythia.org.

The published site is served from the gh-pages branch of the repo, which hasn't seen any new pushes in the last three months.

[brian-rose]

During execution of the deploy workflow, the call to https://github.com/peaceiris/actions-gh-pages is supposed to take the rendered html and push it to the gh-pages branch, which then causes GitHub Pages to actually publish the site.

The latest logs for this step show that nothing is getting pushed:

/usr/bin/git commit -m deploy: 2e4d1f7e4bc947c6d4a70800c5ef8ae5b8738791
[56](https://github.com/ProjectPythia/projectpythia.github.io/actions/runs/4701955054/jobs/8338653215#step:6:61)
  On branch gh-pages
[57](https://github.com/ProjectPythia/projectpythia.github.io/actions/runs/4701955054/jobs/8338653215#step:6:62)
  nothing to commit, working tree clean
[58](https://github.com/ProjectPythia/projectpythia.github.io/actions/runs/4701955054/jobs/8338653215#step:6:63)
  [INFO] skip commit

At the moment I have no idea why. I'll try manually inspecting the build artifact to see if the updated HTML is there.

[brian-rose]

The correct artifact was created during this workflow run. Still a mystery why nothing was committed to the gh-pages branch.

[brian-rose]

@ProjectPythia/infrastructure I don't know what's going on here and may not be able to return to this until early next week.

Until this gets fixed, it seems like we can't make any changes to the portal (unless maybe by manually committing to the gh-pages branch).

I see that in our infrastructure we did Bump peaceiris/actions-gh-pages from 3.9.1 to 3.9.2 on 1/23/2023, and the last successful commit to the gh-pages branch of this repo was on 1/10/2023, e.g. here.

Nothing in the release notes from actions-gh-pages 3.9.2 looks suspicious. The timing could certainly be a coincidence.

[jukent]

When I looked into making a pull request from main into gh-pages, it says there is nothing to compare (?).

[jukent]

It looks like some of our actions that we use are deprecated?

[brian-rose]

When I looked into making a pull request from main into gh-pages, it says there is nothing to compare (?).

the gh-pages branch holds the html files that are generated during the build, i.e. the contents of the _build/html/ directory.

It should be possible to download the zipped build artifact, unzip it, manually commit to a local copy of the gh-pages branch, and thus push back up to GitHub (to the gh-pages branch). That should in turn trigger GitHub Pages to publish the site. I haven't tried it. But that's essentially what the actions-gh-pages action normally does.

[brian-rose]

I think I see the issue now.

The artifact is getting unzipped to path portal/_build/html/, e.g. here

But the actions-gh-pages is looking for the path _build/html, e.g. here

Our reusable workflows aren't set up to handle the case where the build directory is not at the root of the repo. We'll need to fix this.

[ktyle]

Do we need to have a "portal" subdirectory? Can its contents simply be moved up to the root of the repo?

[ktyle]

After looking into this a bit more ... noting that the problem began sometime in January ... on Jan. 27 in #310 , we switched to using the cookbook-actions workflows for the Portal site. I suspect that's what triggered this particular problem ... but not sure why yet.

[brian-rose]

After looking into this a bit more ... noting that the problem began sometime in January ... on Jan. 27 in #310 , we switched to using the cookbook-actions workflows for the Portal site. I suspect that's what triggered this particular problem ... but not sure why yet.

Yes, that's correct. It's because our reusable cookbook actions were never set up to properly handle the path issue I noted above. For some reason we never noticed this problem at the time, maybe because it doesn't trigger a visible CI failure.

I will attempt to fix the actions today. It should be simple.

[brian-rose]

Actually I think @jbusecke already discovered the same problem and has a fix in https://github.com/ProjectPythia/cookbook-actions/pull/45!

[brian-rose]

After merging #331, the site now publishes itself and the new link introduced in #328 is now visible at https://projectpythia.org.

Some further testing in #330 shows that there are still problems with displaying PR previews. I think this has to do with the custom CNAME. I will investigate further.

[jbusecke]

I think I noticed something similar in our docs. Keen to hear what you learn.

[brian-rose]

The problem was already pointed out by @jbusecke in https://github.com/ProjectPythia/cookbook-actions/issues/47. It's not actually about the custom CNAME at all, it's just that our workflows assume we're publishing to a "project site" rather than an "organization site", see https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages.

I will look at fixing / generalizing this.

[brian-rose]

I think this is fully resolved with https://github.com/ProjectPythia/cookbook-actions/pull/59 (and previous attempts).

I successfully tested the preview for the portal site in https://github.com/ProjectPythia/projectpythia.github.io/pull/332 and also tested two of our "project" sites:

• https://github.com/ProjectPythia/cookbook-template/pull/112
• https://github.com/ProjectPythia/pythia-foundations/pull/385

Closing this now.