Open unlikenesses opened 7 years ago
also getting this bug...
@unlikenesses @atav32
It seems you need to include a file named CNAME
at the root of your file structure.
Your custom domain should be the first line in this file.
In my case, the CNAME
file would have this content:
youfoundron.com
Credit goes to this comment.
Just adapt this lines to your DEPLOYMENT script
var ghpages = require('gh-pages');
var fs = require('fs');
fs.writeFile('dist/CNAME', "your-custom-domain.com", function(err) {});
ghpages.publish('dist', function(err) {});
I came across the same issue and just added a npm script for this before publishing.
"add-domain": "echo \"customdomain.com\" > build/CNAME",
If you use gh-pages for React app deployment – just put CNAME
file with your domain into public
folder.
For angular 8. Create a CNAME file inside the src folder. then Inside angular.json "assets": [ "src/favicon.ico", "src/assets", "src/CNAME" // This is the change you need to make. ],
It would be nice if this behavior was documented in the README.
If you use gh-pages for React app deployment – just put
CNAME
file with your domain intopublic
folder.
Thank you it helped
If you are using Gatsby just create a CNAME
file inside the static
folder and put your domain inside it like example.com
I'm using no react just plain html css js. How do I resolve this issue?
As others have said, just put a CNAME file that contains only your domain in the directory that is being published. This will work independently of what tools you are using.
I'm using no react just plain html css js. How do I resolve this issue?
@rjitsu just put a CNAME to your root folder
I have a CNAME file in my root folder and it still resets the domain.. Any suggestions?
@iamlasse
Is the CNAME
file present at root after building for your github pages branch?
If not, which tool are you using to bundle your static assets?
Please see your gh-pages
branch and see if it has a CNAME file in it
For Hugo, I moved the CNAME file to the "public" directory as that is where the static site resources and assets are built by the GitHub Action.
@iamlasse
Is the
CNAME
file present at root after building for your github pages branch?If not, which tool are you using to bundle your static assets?
Yes, the CNAME file is in the root in gh-pages branch with the domain as the only text inside.
same problem here: CNAME file is in the build/ folder, but the custom domain keeps resetting...
same problem here. CNAME available in the gh-pages branch root folder and the GitHub Pages custom domain keeps resetting on every deploy
I was also having this same issue as @dimitarangelko. It turned out the issue was that there were slightly different formats of the link in the CNAME files and In the package.json "add-domain": script line
it was "add-domain": "echo \"https://mypage.app\" > build/CNAME", and it had https://mypage.app/ in the gh-pages branch CNAME file, but had just mypage.app in the master branch CNAME file. I switched them all to just mypage.app like so
public/CNAME (in master): mypage.app CNAME file (in GH-Pages): mypage.app and in package.json: "add-domain": "echo \"mypage.app\" > build/CNAME",
made sure that the correct domain was set up in github pages before doing this and pulled them in in the gh-pages branch. Saved it all and ran npm run deploy and it finally didn't replace it!
CNAME file is in my main and gh-pages branches, and at the root of each. But this still happens. Any ideas?
I'm building a Vite React app, I use GitHub actions to build and push to gh-pages branch.
For Hugo (as mentioned above) you can add the CNAME like so from the root of your directory:
$ mkdir -p public
$ echo 'www.<yourdomain>.com' > public/CNAME
Adding this because I wasn't sure exactly where the public directory should be, and I didn't know what a CNAME file contained.
I have the same problem using Hugo.
gh-pages
main
and gh-pages
I think this worked fine before the option deploy using github actions
, and I never chose this option because I have my own actions to build and update the branch gh-pages
. I think that the problem is something in the new way that github handles the deployment.
I have the same problem using Hugo.
- I'm using the deploy from branch
gh-pages
- the CNAME is set in both branches
main
andgh-pages
I think this worked fine before the option
deploy using github actions
, and I never chose this option because I have my own actions to build and update the branchgh-pages
. I think that the problem is something in the new way that github handles the deployment.
I am using Sphinx, but I fixed this by adding CNAME to the directory from which Pages deploys the source.
E.g., if your build.yml
is directing Pages to use the build/
subfolder of root for deployment, then add CNAME
to build/
in the main branch.
I have the same problem using Hugo.
- I'm using the deploy from branch
gh-pages
- the CNAME is set in both branches
main
andgh-pages
I think this worked fine before the option
deploy using github actions
, and I never chose this option because I have my own actions to build and update the branchgh-pages
. I think that the problem is something in the new way that github handles the deployment.I am using Sphinx, but I fixed this by adding CNAME to the directory from which Pages deploys the source.
E.g., if your
build.yml
is directing Pages to use thebuild/
subfolder of root for deployment, then addCNAME
tobuild/
in the main branch.
I do that. https://github.com/fguisso/fguisso.github.io/blob/gh-pages/CNAME
I follow the file to show to you and noticing that every deploy removes de CNAME file, but this actions is not setting by me: https://github.com/fguisso/fguisso.github.io/commits/gh-pages/CNAME
I am deploying a GatsbyJS site to GitHub pages with this command:
gatsby build --prefix-paths && gh-pages -d public -b master
I need to push to the master branch because it's a user site (rather than a project site). This works but each time I do it, the repo's "Custom domain" setting is reset. This means after every deploy I need to go into the settings and re-enter the custom domain. No idea if this is a bug or if I'm just missing something obvious.