Replies: 11 comments 32 replies
-
Hello! Just wanted to chime in here to confirm that this is something we have plans for. No ETA yet as it has not been committed to the roadmap but we are doing prep work in the next few months that will help us achieve this in the medium term. |
Beta Was this translation helpful? Give feedback.
-
Not sure if this is helpful for you. But I
Not sure if this is helpful, with a bit of fiddling around you can make your own deployment preview system just using basic GitHub actions. I have made one for a react project. While we wait for GitHub to release a proper solution, I encourage you to have a tinker. My solution if your interested generates a repository then builds the project, finally it deploys it to the new repository and posts a comment to the preview url. |
Beta Was this translation helpful? Give feedback.
-
I think the former would be much preferable because it would not represent a change to the Maybe take the lead from Netlify, who has urls like
|
Beta Was this translation helpful? Give feedback.
-
Given the fact that GitHub Actions can now be used to deploy to GitHub Pages am I wondering something... There is the option to define extra enviroment variables from what I saw, and given my prior experience with other deploy tools like Netlify or Vercel, these seem to be used to also define deploy enviroments? If not would I like to hear any (and I mean any) updates regarding this. I know it's a lot of work and it may not be on any roadmap (either public or private) yet, but at least a confirmation that it's not forgotton would be nice. |
Beta Was this translation helpful? Give feedback.
-
I guess there is some progress: https://github.com/actions/deploy-pages/blob/368bf1aa22b9265440e251b9216520e3f91c2d5b/action.yml#L36-L39 |
Beta Was this translation helpful? Give feedback.
-
@JamesMGreene / @yoannchaudet any update on this request? |
Beta Was this translation helpful? Give feedback.
-
Looking back at this, I feel like there could also be a use for defining your own custom (sub-)domain for deploy previews to use, just in case you want things to look more professional. Alternatively have an option in the configuration file, if said file would be used. Just a random idea... |
Beta Was this translation helpful? Give feedback.
-
@yoannchaudet any update on when this will ship? My team could really use this feature, I've been crossing my fingers.. Would be amazing to have, +1 to @Andre601s suggestion on a custom domain. Even better if it can be defined within the workflow itself, without having to create the CNAME file directly (I believe a widely used mkdocs deploy Actions plugin behaves this way)🤞 |
Beta Was this translation helpful? Give feedback.
-
Not sure if it is too late to suggest ways of doing this, but if it isn't have I found a solution another service uses, which I find quite decent. On that other service can you put |
Beta Was this translation helpful? Give feedback.
-
See also actions/deploy-pages#337 |
Beta Was this translation helpful? Give feedback.
-
This would be a really great feature for our organisation. |
Beta Was this translation helpful? Give feedback.
-
Context
When using GitHub Pages for things such as static pages or documentation is one thing almost always used alongside it: Deploy previews.
There exist many services such as Netlify and Vercel which do offer deploy previews with GitHub support, so that you can see how changes from a PR may look like.
The issue I (and probably some others) have with this is, that they either come with some limitations (i.e. limited bandwidth) or features that you can't disable and don't need (i.e. having a constant page deployment while you only need previews). This combined with the fact that some features are behind paywalls or a (sometimes) difficult configuration makes this a not so enjoyable experience.
The Idea
There should be an option to have Deploy previews using GitHub Pages. This would allow to have the main docs and any deploy preview hosted on the same place which would be GitHub (GitHub Pages).
This could reduce the required amount of configuration as you don't have to first authorize apps and sites, setup the files and dashboard settings, etc.
How it would work
Under the "Pages" tab of the Repository-setting would be a section where you can enable the deploy previews.
Clicking the button would open up the online editor, where you would create a YAML file inside the
.github
directory (i.e..github/deploy-preview.yml
).This file could have a somewhat similar setup to GitHub Actions, which would allow a much higher level of configuration for when and where to build things.
As an example could you define required labels to build the preview.
Here is a small example of the file:
If someone would now make a PR and this PR meets the requirements would GitHub take the information from the PR and build it according to the configuration.
The preview would then be deployed to a specific subdomain such as
preview-<pr-id>.<username>.github.io
or perhapspreview.<username>.github.io/<pr-id>/...
depending on what would be doable from your end.Final Words
I hope this is an interesting idea. I love GitHub Pages and I really hate to rely on external services to have deploy previews for Pull requests where the final page will end up on GitHub Pages anyway.
This idea would perhaps improve the flow of how you could handle deploy previews by having everything at one place. Less sites to worry about and less risk by not having authorization on other pages...
Beta Was this translation helpful? Give feedback.
All reactions