Comments (9)
👋 Just to confirm this is not supported today. Deployments are "atomic operations" currently. We may expend in the future but there is no concrete plan at the moment.
Your best bet today would be to leverage our path based routing mechanism.
The root of your website can be tracked in a <username>.github.io
repository. Anything you want to live at /<path>
on that side, you just need to put in a repository named after the path, e.g. a notebook
repository would publish content under <username>.github.io/notebook
. If you have a custom domain set for your <username>.github.io
repository, this will work accordingly.
from deploy-pages.
Adding another voice to this request.
I have branch-based workflows now and want to publish partial changes: basically, I want an "atomic" update but to a specific directory, while not affecting other directories.
One way that support for this could be added without changing the publish process, is to give us a way to download the entire current published site as an archive.
That could allow us to handle this in the "build" portion of the workflow, and leave the publish process unchanged.
It might look something like this:
jobs:
# Build job
build:
permissions:
pages: read # ???
contents: read
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Pull existing site
id: read_pages
uses: actions/read-pages@v1 # ???
- name: extract existing site
run: tar -xvf "${{ steps.read_pages.outputs.archive }}" -C site/
- name: Build process
working-directory: site
run: |
# do build process to modify just what needs to be changed
# upload artifact of whole site using actions/upload-pages-artifact
# Deploy job (copied directly from README, no modification here)
deploy:
# Add a dependency to the build job
needs: build
# Grant GITHUB_TOKEN the permissions required to make a Pages deployment
permissions:
pages: write # to deploy to Pages
id-token: write # to verify the deployment originates from an appropriate source
# Deploy to the github-pages environment
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
# Specify runner + deployment step
runs-on: ubuntu-latest
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v1
from deploy-pages.
FWIW, I've added an item to the Pages team backlog to consider this in the future. No promises that it will happen or any forecasted timeline, though. ❤️
from deploy-pages.
New
from deploy-pages.
@briantist As Yoann mentioned, incremental deployments are not a planned feature at the moment for GitHub Pages. There was some notion of this in the past but it was a source of security vulnerabilities exploited by bad actors.
As for a recommended workaround, I might suggest having your "build" workflow operate on your default branch (e.g. main
), but then push its built changes into a second branch/tag/Release to maintain the assets for the published site. Resolving any necessary merging of assets would be up to you. You could either pull the previously published assets into your build workspace before or after running the build of your latest code. 🤷🏻♂️
from deploy-pages.
Hey @JamesMGreene , this is currently what I do, the exciting thing about this newer actions-based deployment model is not having to commit and push, which requires permissions I don't want, and commit history I don't need. Pushing the assets into a branch seems to be re-implementing the current gh-pages
-based workflow.
Anyway, while I understand that incremental deployments are not a planned feature, the workaround I suggested does not require you to implement any special support for incremental deploys at all, it only requires one thing: let us download the full contents of the currently published site.
That would let us access the previously published assets and merge them as needed (or do whatever with them).
Where would be the best place to request a very simple action to download the site contents?
- name: Pull existing site
id: read_pages
uses: actions/read-pages@v1 # ???
from deploy-pages.
I also came here looking for a place to ask about a download-pages-artifact
type action to compliment the upload-pages-artifact
action. I think this is the same as @briantist's proposed solution – allowing users to decide how to merge in new content in their build step.
Is there a way to get all the content of a current pages deployment?
from deploy-pages.
Is there a way to get all the content of a current pages deployment?
There is not currently a way to retrieve or reconstruct a Pages site's artifact after it is deployed today (or at least once the artifact's retention period has expired).
💡 It is an interesting idea, though! Definitely open to considering adding backend support and a separate Action for it in the future, but it's not something we can prioritize right now. 😕
If you wanted to work around it for now (without using a gh-pages
style branch 😓), you could probably also create a less performant option by:
- Including some sort of manifest file (JSON, YAML, XML, whatever) cataloguing all of the files to be included in your Packages artifact, and then include that file in the artifact as well
- Creating an Action or script to subsequently download that manifest file, and then download each of the catalogued assets (plus needing to create directory structures, etc.).
It's not pretty, but just wanted to pitch the idea in case it helps. 🤞🏻 🤷🏻
from deploy-pages.
Related:
from deploy-pages.
Related Issues (20)
- Failing to fetch artifact metadata since 4.0.0 HOT 8
- Bump to V4 broke the deploy step HOT 9
- Remove requirement for `actions: read` permission HOT 1
- Unhelpful Error HOT 5
- Page Deployment Failing Periodically with Timeouts since Upgrade to v4 HOT 1
- Getting "Fetching artifact metadata failed." HOT 3
- Confusing error when trying to deploy Rust docs HOT 6
- CNAME file doesn't work to set custom domain
- Error: No artifacts named "github-pages" were found for this workflow run. HOT 5
- Deploy to another repository HOT 2
- GitHub Enterprise Server 3.11.5 compatibility HOT 6
- Deployment protection rules seem to be ignored HOT 1
- 502 error on github enterprise HOT 3
- More clarity on id-token: write HOT 11
- Artifact could not be deployed; no symlinks or hard links, small size HOT 1
- When the preview feature will be available
- Allow deploy by artifact_id
- Problem in page deployment with vuejs vite to github page HOT 8
- Value 'github-pages' is not valid HOT 3
- Astro Site: Please ensure the content does not contain any hard links, symlinks and total size is less than 10GB HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from deploy-pages.