-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update to new github pages build system #416
Comments
Okay I'm getting myself confused here on how to proceed so could use some help. So on to where I'm confused. Based on the GitHub docs, all I need to do in https://github.com/ansible-community/nightly-builds is enable GitHub actions. But this blog post suggests there's more work to do than just enable GH actions in the repo. And the email from Github says: And I see no warning on the Pages setting in https://github.com/ansible-community/nightly-builds BUT GH Actions are disabled in that repo. And finally, the actual workflow that seems to update these pages comes from the antsibull repo (where it's using someone else's github actions). So I'm inclined to enable GHA in the nightly-builds repo, manually trigger the antsibull workflow, and see what happens. Finally, I do think we shoud start using the GHA for pages that are from github, not that third party one. |
@felixfontein @webknjaz what do you think about ^^? I'll turn on GHA later today in the nightly-build repo to see what happens but would like your thoughts on if I need to do more. |
My guess is that the repo is populated by GA from https://github.com/ansible-community/antsibull/blob/main/.github/workflows/build-dumb-pypi.yml, so enabling GHA in https://github.com/ansible-community/nightly-builds doesn't make sense. |
Hmm, we're also using I'll do some tests with this tomorrow. |
(I'm somewhat surprised that we didn't get this warning for all the other repositories in github.com/ansible-collections that use the legacy way of publishing docs as well.) |
yes, I'm finding it difficult to see how to replace the old third-party GHA (https://github.com/ansible-community/antsibull/blob/main/.github/workflows/build-dumb-pypi.yml#L193) with the new GHA from Github. The old one allows you to push to an external repo (nightly builds) but the new one doesn't. |
Actions are enabled for community.docker - https://github.com/ansible-collections/community.docker/settings/actions |
I don't think so; you also need to change the source for the built pages, and install a workflow for publishing (if it's not already there). For the nightly repo, that workflow must not be in the |
So for community.docker - it is using the 'new way '. Notice in the actions it has https://github.com/ansible-collections/community.docker/actions/workflows/pages/pages-build-deployment now |
Sorry @felixfontein - not understanding your prior comment? |
It is not. It is simply storing the raw pages on the
Is basically the legacy GitHub Pages build system. (It doesn't exist as a workflow in the repo.) |
(In case you looked into the settings: I changed it to "source: GHA" for that repo to see what actually happens then; I didn't intend to actually change it now, but it seemed to have auto-changed it. It's now back to its original value: "Deploy from a branch") |
This is what GitHub emailed Hello, We are writing to inform you about an important update regarding GitHub Pages that could impact one or multiple sites you own. What is happening? Delivering on our continued commitment to enhance security, protect your data, and deliver an overall improved experience, we will be shutting down our legacy pagesworker architecture by June 30th 2024. What is replacing legacy pagesworker? Since August 2022, GitHub Pages sites have been built and deployed with GitHub Actions. However for repositories where Actions is unavailable, we used the legacy pagesworkers for Pages builds and deployments. Going forward, GitHub Actions will become a requirement for deploying Pages sites that require a build step, such as those utilizing Jekyll. We chose to implement this change because GitHub Actions provides developers a modern, secure sandbox that surpasses the capabilities of pagesworker. With GitHub Actions, you get your choice of operating system, log streaming, dependency caching, custom gates, and modern CI/CD features. Additionally, we are pleased to announce the general availability of the feature allowing you to delegate Pages deployments to GitHub Actions alongside a source branch. How can I tell if my Pages site will be impacted? If your Pages site is being built by the legacy infrastructure, a warning message will be displayed in your Pages settings starting today. Note that the vast majority of pages sites have already been leveraging GitHub Actions. We will only fall back to the legacy build infrastructure if GitHub Actions is unavailable in your repository. Transitioning to Actions Transitioning your Pages builds from pagesworker to Actions is straightforward. Simply enable Actions in your repository settings to ensure your site continues to build. For those on legacy paid plans (Gold, Silver, etc.) where Actions is unavailable, we suggest the following:
|
FWIW I still think the pages should be moved into the build-data repo or antsibull. The reason is that it'll get more complicated to trigger stuff cross-repos. One of the original workflow intentions was to catch regressions in the packaging automation there. It's not just about serving the files as a nightly package index, I remember it did catch problems with the automation in the past. |
I'm not sure it's a good idea to move it there, since the files in that repo take up quite some space (especially if old commits are kept around / still referenced somehow), so this could accidentally blow up these repos with temp files that really don't belong in them. |
@felixfontein with the GHA-based GH Pages publishing it won't use the Git storage/branches, it'll create a GHA workflow artifact and then publish it. I suppose we could also auto-delete it (I don't remember if GH does that automatically). |
I still don't think this should be added to either the antsibull or the ansible-build-data repos.
That depends on how it is set up. The way GitHub recommends in the blog post, it uses a branch from the repo. I guess it can now be done without that, but I think it should still be done in a separate repo. |
Just checked https://github.com/ansible/pylibssh/actions/runs/9465600458#artifacts and I see that all the workflow artifacts are expired, which reminded me of the retention setting. So I've gone to the action and confirmed that it's just one day: https://github.com/actions/upload-pages-artifact/blob/1780dfc/action.yml#L16. Interestingly, the action README talks about 10 GB being the maximum size. I remember the old-style GH Pages being kept under 500 MB. |
That is the old-style mechanism that's being phased out. The new thing only needs a GHA workflow and everything's generated inside. I've been using it in 3-4 repos over the past few years. |
ansible-community/github-docs-build#92 describes a solution for the docs publishing workflows. I'll look at the nightly builds tomorrow. |
I pushed a modified version of the workflow to https://github.com/ansible-community/nightly-builds/blob/main/.github/workflows/build-dumb-pypi.yml which should publish to GH Pages using the new mechanism (see the last few steps of the workflow), and I've created ansible-community/antsibull-build#608 to remove the workflow from the antsibull repository. |
Closing since this has been resolved. If you want to improve the workflow, feel free to create PRs :) |
Thanks @felixfontein !! |
ansible-community/nightly-builds apparently still uses the legacy GitHub Pages build system
Need to be moved to the new system https://github.blog/2022-08-10-github-pages-now-uses-actions-by-default/
there's an example of doing this in ansible/pylibssh (at the bottom of ci-cd.yml)
The text was updated successfully, but these errors were encountered: