Codeberg/Community
54
325
Fork
You've already forked Community
12

Codeberg pages use different branch on custom domain than on codeberg.page domain #1781

Open
opened 2025年01月31日 16:26:31 +01:00 by stepanzak · 8 comments

Comment

facts:

  • I have repo with a website on https://codeberg.org/stepanzak/pages .
  • It has two branches: main and pages .
  • In the main branch, there are source files for the zola static site generator.
  • On every push on main, woodpecker ci runs a job that builds the static site using zola and pushes the output to the pages branch.
  • The generated static site is available at https://stepanzak.codeberg.page .
  • I have a domain, stepanzak.cc, managed fully with CloudFlare.
  • The domain has ony following DNS records:
  • image
  • For the CNAME at the apex domain, CloudFlare uses CNAME flattening, so it's actually like ALIAS. That's why I also have the TXT record in there

the problem:

When I visited https://stepanzak.cc , it displayed Codeberg pages 404 error. I spent a lot of time trying to figure out why, then I thought maybe it's serving from the main branch. I added index.html to main as a test, and it worked.
So, now I have https://stepanzak.codeberg.page being served from the pages branch, and https://stepanzak.cc being served from the main branch.

expected behavior:

I would expect both codeberg.page and custom domain to behave consistently, serving from the pages branch.

### Comment ### facts: - I have repo with a website on https://codeberg.org/stepanzak/pages . - It has two branches: _main_ and _pages_ . - In the _main_ branch, there are source files for the [zola](https://www.getzola.org) static site generator. - On every push on _main_, woodpecker ci runs a job that builds the static site using zola and pushes the output to the _pages_ branch. - The generated static site is available at https://stepanzak.codeberg.page . - I have a domain, stepanzak.cc, managed fully with CloudFlare. - The domain has ony following DNS records: - ![image](/attachments/bbe99fff-1d29-4a41-a4ea-91a8159661c8) - For the CNAME at the apex domain, CloudFlare uses CNAME flattening, so it's actually like ALIAS. That's why I also have the TXT record in there ### the problem: When I visited https://stepanzak.cc , it displayed Codeberg pages 404 error. I spent a lot of time trying to figure out why, then I thought maybe it's serving from the _main_ branch. I added index.html to _main_ as a test, and it worked. So, now I have https://stepanzak.codeberg.page being served from the _pages_ branch, and https://stepanzak.cc being served from the _main_ branch. ### expected behavior: I would expect both codeberg.page and custom domain to behave consistently, serving from the _pages_ branch.

This might be taken into account for the newer pages server (CC @crapStone) but I'm afraid for the existing pages server this will be too much of a breaking change to fix this behavior. FWIW the relevant code is (this is only a bug for repositories named pages)

iftargetBranch==""&&targetRepo!=defaultPagesRepo{
targetBranch=firstDefaultBranch
}
This might be taken into account for the newer pages server (CC @crapStone) but I'm afraid for the existing pages server this will be too much of a breaking change to fix this behavior. FWIW the relevant code is (this is only a bug for repositories named `pages`) https://codeberg.org/Codeberg/pages-server/src/commit/9450415545d945e3e2061b60cb3da5f79f6f305d/server/dns/dns.go#L61-L63

@Gusted wrote in #1781 (comment):

This might be taken into account for the newer pages server (CC @crapStone) but I'm afraid for the existing pages server this will be too much of a breaking change to fix this behavior.

Hmm, I'm not sure whether fixing this would break someone's setup. I might be wrong, but I don't think anyone somehow uses the fact that the custom domain uses different branch than the codeberg.page domain for their advantage.
IMO if someone has a pages branch in their pages repo, they probably want the page to be served from that branch. It works like that on the codeberg.page domain anyways.
However you decide, noting it in the documentation would be great, as it took me significant amount of time to figure it out :)

this is only a bug for repositories named pages

As I have a custom domain anyways, renaming the repo to something other than pages is probably what I'll do.

@Gusted wrote in https://codeberg.org/Codeberg/Community/issues/1781#issuecomment-2664940: > This might be taken into account for the newer pages server (CC @crapStone) but I'm afraid for the existing pages server this will be too much of a breaking change to fix this behavior. Hmm, I'm not sure whether fixing this would break someone's setup. I might be wrong, but I don't think anyone somehow uses the fact that the custom domain uses different branch than the codeberg.page domain for their advantage. IMO if someone has a _pages_ branch in their _pages_ repo, they probably want the page to be served from that branch. It works like that on the codeberg.page domain anyways. However you decide, noting it in the documentation would be great, as it took me significant amount of time to figure it out :) > this is only a bug for repositories named `pages` As I have a custom domain anyways, renaming the repo to something other than `pages` is probably what I'll do.

I think that I have the same problem so what should I do?

I have a USERNAME. Under it, I have a repository pages. In the repository pages, my code is on main branch. On th CI, I build my main branch and push the artifact to an orphan pages branch.

What should I have on my registrar?

your.domain.com	A	217.197.91.145
your.domain.com	AAAA	2001:67c:1401:20f0::1
your.domain.com	TXT	pages.pages.USERNAME.codeberg.page
www.your.domain.com	CNAME	yourdomain.com

right?

Then both USERNAME.codeberg.page and your.domain.com should display the main's artifact, shouldn't they?

Beside what should contain the .domains ?

I guess

your.domain.com	
pages.pages.USERNAME.codeberg.page

or maybe

your.domain.com	
USERNAME.codeberg.page

I read the documentation and a few tutorials but it seems that I am still failing

I think that I have the same problem so what should I do? I have a USERNAME. Under it, I have a repository `pages`. In the repository `pages`, my code is on `main` branch. On th CI, I build my `main` branch and push the artifact to an orphan `pages` branch. What should I have on my registrar? ``` your.domain.com A 217.197.91.145 your.domain.com AAAA 2001:67c:1401:20f0::1 your.domain.com TXT pages.pages.USERNAME.codeberg.page www.your.domain.com CNAME yourdomain.com ``` right? Then both `USERNAME.codeberg.page` and `your.domain.com` should display the main's artifact, shouldn't they? Beside what should contain the `.domains` ? I guess ``` your.domain.com pages.pages.USERNAME.codeberg.page ``` or maybe ``` your.domain.com USERNAME.codeberg.page ``` I read the documentation and a few tutorials but it seems that I am still failing - https://docs.codeberg.org/codeberg-pages/using-custom-domain/ - https://blog.ummit.dev/posts/web/codeberg/how-to-host-static-websites-with-codeberg-pages-and-custom-domain/
Member
Copy link

@D4llo The default branch is always used for the pages repository, and this behavior is expected. If you are uploading your site to the pages repository, you should use the default branch for the static contents and another branch or another repo for the source code.

(削除) The DNS records you posted above look fine, except for the CNAME for www, which should point to your.domain.com. and not yourdomain.com if you want the Codeberg Pages server to redirect it to your.domain.com for you. (削除ここまで) Actually, you used the wrong A and AAAA records too. Those should point to 217.197.84.141 and 2a0a:4580:103f:c0de::2 respectively. The CNAME record for www should point to your.domain.com.

Inside the .domains file, you only need the following

your.domain.com
www.your.domain.com

codeberg.page does not need to be listed in the .domains file at all. The second line is necessary if you wish to have www.your.domain.com redirect to your.domain.com using the CNAME record as described above.

You need to fix the default branch problem described in the first paragraph if you want <username>.codeberg.page to redirect to your custom domain.

Btw, I have written a script that verifies the Codeberg Pages setup for your custom domain and gives you suggestions for fixing it, use the following command if you want to try it.

curl https://troubleshoot.codeberg.page/verify.sh | bash -s <custom-domain>

@D4llo The default branch is always used for the `pages` repository, and this behavior is **expected**. If you are uploading your site to the `pages` repository, you should use the default branch for the static contents and another branch or another repo for the source code. ~~The DNS records you posted above look fine, except for the CNAME for `www`, which should point to `your.domain.com.` and not `yourdomain.com` if you want the Codeberg Pages server to redirect it to `your.domain.com` for you.~~ Actually, you used the wrong A and AAAA records too. Those should point to `217.197.84.141` and `2a0a:4580:103f:c0de::2` respectively. The CNAME record for `www` should point to `your.domain.com.` Inside the `.domains` file, you only need the following ``` your.domain.com www.your.domain.com ``` codeberg.page does not need to be listed in the .domains file at all. The second line is necessary if you wish to have `www.your.domain.com` redirect to `your.domain.com` using the CNAME record as described above. You need to fix the default branch problem described in the first paragraph if you want `<username>.codeberg.page` to redirect to your custom domain. Btw, I have written a script that verifies the Codeberg Pages setup for your custom domain and gives you suggestions for fixing it, use the following command if you want to try it. `curl https://troubleshoot.codeberg.page/verify.sh | bash -s <custom-domain>`

@crystal Where did you get those IPs? Codeberg's documentation uses 217.197.91.145 and 2001:67c:1401:20f0::1 as I do. In the doc, the CNAME point to username.codeberg.page and not your.domain.com

from the documentation:

Domain Type Data
yourdomain.comA217.197.91.145
yourdomain.comAAAA2001:67c:1401:20f0::1
yourdomain.comTXTreponame.username.codeberg.page
www.yourdomain.comCNAMEreponame.username.codeberg.page

What I understood from the doc for my case:

Domain Type Data
yourdomain.comA217.197.91.145
yourdomain.comAAAA2001:67c:1401:20f0::1
yourdomain.comTXTUSERNAME.codeberg.page
www.yourdomain.comCNAMEUSERNAME.codeberg.page

(I don't need reponame because my repo and my targeting branch are both called pages

What you say I should do:

Domain Type Data
yourdomain.comA217.197.84.141
yourdomain.comAAAA2a0a:4580:103f:c0de::2
yourdomain.comTXTUSERNAME.codeberg.page
www.yourdomain.comCNAMEyourdomain.com

So what should I do?

About the .domains, most example in the docs have both a example.com and a codeberg page link pages.colormix.frida.codeberg.page. Should I change that too?

@crystal Where did you get those IPs? Codeberg's documentation uses `217.197.91.145` and `2001:67c:1401:20f0::1` as I do. In the doc, the CNAME point to `username.codeberg.page` and not `your.domain.com` from the documentation: <table class="table"> <thead> <th>Domain</th> <th>Type</th> <th>Data</th> </thead> <tbody> <tr> <td>yourdomain.com</td><td>A</td><td>217.197.91.145</td> </tr> <tr> <td>yourdomain.com</td><td>AAAA</td><td>2001:67c:1401:20f0::1</td> </tr> <tr> <td>yourdomain.com</td><td>TXT</td><td>reponame.username.codeberg.page</td> </tr> <tr> <td>www.yourdomain.com</td><td>CNAME</td><td>reponame.username.codeberg.page</td> </tr> </table> What I understood from the doc for my case: <table class="table"> <thead> <th>Domain</th> <th>Type</th> <th>Data</th> </thead> <tbody> <tr> <td>yourdomain.com</td><td>A</td><td>217.197.91.145</td> </tr> <tr> <td>yourdomain.com</td><td>AAAA</td><td>2001:67c:1401:20f0::1</td> </tr> <tr> <td>yourdomain.com</td><td>TXT</td><td>USERNAME.codeberg.page</td> </tr> <tr> <td>www.yourdomain.com</td><td>CNAME</td><td>USERNAME.codeberg.page</td> </tr> </table> (I don't need `reponame` because my repo and my targeting branch are both called `pages` What you say I should do: <table class="table"> <thead> <th>Domain</th> <th>Type</th> <th>Data</th> </thead> <tbody> <tr> <td>yourdomain.com</td><td>A</td><td>217.197.84.141</td> </tr> <tr> <td>yourdomain.com</td><td>AAAA</td><td>2a0a:4580:103f:c0de::2</td> </tr> <tr> <td>yourdomain.com</td><td>TXT</td><td>USERNAME.codeberg.page</td> </tr> <tr> <td>www.yourdomain.com</td><td>CNAME</td><td>yourdomain.com</td> </tr> </table> So what should I do? About the `.domains`, most example in the docs have both a `example.com` and a codeberg page link `pages.colormix.frida.codeberg.page`. Should I change that too?
Member
Copy link

@D4llo

Where did you get those IPs? Codeberg's documentation uses 217.197.91.145 and 2001:67c:1401:20f0::1 as I do. In the doc, the CNAME point to username.codeberg.page and not your.domain.com

I got those addresses by doing my own lookups for codeberg.page. The addresses were changed recently and the documentation has apparently not yet been updated.

(I don't need reponame because my repo and my targeting branch are both called pages

That is incorrect. If you do not supply a repo name, it will use the pages repo by default, but it will use the default branch in that case, not the pages branch. It uses the pages branch by default only if a different repository name is specified. You may be able to workaround this by setting the pages branch as the default branch for the pages repo, but ymmv.

So what should I do?

The CNAME will technically work both ways, but the setup described in the documentation with your www record pointing to the respective *.codeberg.page. is preferred because it reduces the number of required DNS lookups. You should also probably not point the CNAME record to your apex domain if you have any email service on that domain.

The A and AAAA records must point to the new addresses.

About the .domains, most example in the docs have both a example.com and a codeberg page link pages.colormix.frida.codeberg.page. Should I change that too?

The docs are wrong about that. Technically, it won't break anything, but it's not doing any good either. You must have both example.org and www.example.org in your .domains file if you wish to have Codeberg Pages handle www-apex redirect (put whichever one you want to be canonical on the first line). You never need any codeberg.page domain in there.

@D4llo > Where did you get those IPs? Codeberg's documentation uses 217.197.91.145 and 2001:67c:1401:20f0::1 as I do. In the doc, the CNAME point to username.codeberg.page and not your.domain.com I got those addresses by doing my own lookups for codeberg.page. The addresses were [changed recently](https://codeberg.org/Codeberg/pages-server/pulls/454) and the documentation has apparently not yet been updated. > (I don't need `reponame` because my repo and my targeting branch are both called `pages` That is incorrect. If you do not supply a repo name, it will use the `pages` repo by default, but it will use the default branch in that case, not the `pages` branch. It uses the `pages` branch by default only if a different repository name is specified. You may be able to workaround this by setting the `pages` branch as the default branch for the `pages` repo, but ymmv. > So what should I do? The CNAME will technically work both ways, but the setup described in the documentation with your `www` record pointing to the respective `*.codeberg.page.` is preferred because it reduces the number of required DNS lookups. You should also probably not point the CNAME record to your apex domain if you have any email service on that domain. The A and AAAA records must point to the _new_ addresses. > About the `.domains`, most example in the docs have both a `example.com` and a codeberg page link `pages.colormix.frida.codeberg.page`. Should I change that too? The docs are wrong about that. Technically, it won't break anything, but it's not doing any good either. You must have both `example.org` and `www.example.org` in your .domains file if you wish to have Codeberg Pages handle www-apex redirect (put whichever one you want to be canonical on the first line). You never need any `codeberg.page` domain in there.

Alright thanks a lot for all the informations! So my DNS table should be:

Domain Type Data
your.domain.comA217.197.84.141
your.domain.comAAAA2a0a:4580:103f:c0de::2
your.domain.comTXTpages.pages.USERNAME.codeberg.page
www.your.domain.comCNAMEyour.domain.com

and in the .domains:

your.domain.com
www.your.domain.com

I will try that

Alright thanks a lot for all the informations! So my DNS table should be: <table class="table"> <thead> <th>Domain</th> <th>Type</th> <th>Data</th> </thead> <tbody> <tr> <td>your.domain.com</td><td>A</td><td>217.197.84.141</td> </tr> <tr> <td>your.domain.com</td><td>AAAA</td><td>2a0a:4580:103f:c0de::2</td> </tr> <tr> <td>your.domain.com</td><td>TXT</td><td>pages.pages.USERNAME.codeberg.page</td> </tr> <tr> <td>www.your.domain.com</td><td>CNAME</td><td>your.domain.com</td> </tr> </table> and in the `.domains`: ``` your.domain.com www.your.domain.com ``` I will try that

I think it is working for us now https://d-edge.solidairesinformatique.org/

I think it is working for us now https://d-edge.solidairesinformatique.org/
Sign in to join this conversation.
No Branch/Tag specified
main
No results found.
Labels
Clear labels
accessibility

Reduces accessibility and is thus a "bug" for certain user groups on Codeberg.
bug

Something is not working the way it should. Does not concern outages.
bug
infrastructure
Errors evidently caused by infrastructure malfunctions or outages
Codeberg

This issue involves Codeberg's downstream modifications and settings and/or Codeberg's structures.
contributions welcome

Please join the discussion and consider contributing a PR!
docs

No bug, but an improvement to the docs or UI description will help
duplicate

This issue or pull request already exists
enhancement

New feature
infrastructure

Involves changes to the server setups, use `bug/infrastructure` for infrastructure-related user errors.
legal

An issue directly involving legal compliance
licence / ToS

involving questions about the ToS, especially licencing compliance
please chill
we are volunteers
Please consider editing your posts and remember that there is a human on the other side. We get that you are frustrated, but it's harder for us to help you this way.
public relations

Things related to Codeberg's external communication
question

More information is needed
question
user support
This issue contains a clearly stated problem. However, it is not clear whether we have to fix anything on Codeberg's end, but we're helping them fix it and/or find the cause.
s/Forgejo

Related to Forgejo. Please also check Forgejo's issue tracker.
s/Forgejo/migration

Migration related issues in Forgejo
s/Pages

Issues related to the Codeberg Pages feature
s/Weblate

Issue is related to the Weblate instance at https://translate.codeberg.org
s/Woodpecker

Woodpecker CI related issue
security

involves improvements to the sites security
service

Add a new service to the Codeberg ecosystem (instead of implementing into Gitea)
upstream

An open issue or pull request to an upstream repository to fix this issue (partially or completely) exists (i.e. Gitea, Forgejo, etc.)
wontfix

Codeberg's current set of contributors are not planning to spend time on delegating this issue.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Codeberg/Community#1781
Reference in a new issue
Codeberg/Community
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?