This project was (re)generated using Angular CLI version 22.0.4.

Codeberg has two different CI systems : Codeberg CI also called Woodpecker CI on the one hand, and Forgejo Actions on the other hand. We will use Forgejo Actions.
(It can be confusing as both systems use YML files to describe workflows, but Forgejo Actions are more modular and don't require whitelisting/registration. Also I'm not sure whether Woodpecker can deploy to Pages.)

Create a repo on Codeberg. Unless Codeberg changes its rules for CI usage, the repo needs to be public and under a free license (this applies for both CI systems).
In your repo settings, then Units, then Overview, check the Actions box.

To set up the domain name and DNS settings, follow this tutorial, using the "If you deploy from Forgejo Actions" alternatives where applicable.

Copy the .forgejo folder to the root of your repo. In the YML file, replace the domain name with the one you set up.

You can actually set up several deployments to different domain names on the same repo, something which does not seem possible with GitHub and is harder to do in GitLab.
One way to do that is to duplicate the section starting with - uses: actions/git-pages, using another domain name, as depicted in this example (provided you set up the DNS for each used domains). If you need to use different build parameters for the different domains, you can always duplicate the whole YML file.
For most uses, you will need only one of these sections.

Redirecting all routes to the main page, in case your Angular app has several routes, is done using the codeberg_pages_redirect file in the root of the project, handled by a specific line in the workflow file (reference). Angular projects with a single root route do not need this.

Create a repo on Gitlab. It may be a private repo.
In the case where the repo is private, if you want the website to be publicly accessible, you need to go to the repo's "Settings" > "General" > "Visibility", scroll down to "Pages", and select "Everyone".

Either push directly to that repo, or set up a mirror to that repo from your main forge.
From Codeberg, you need to go in the project "Settings", section "Mirror settings", and add a push mirror. The url needs to be the .git url of the GitLab repo, the username is yours and the password is a GitLab Token.
To create a token for your whole GitLab account, go in your account "Preferences", then "Access" > "Personal Access Tokens". It needs to have the 6 following scopes : Code: Push, Read ; Commit: Update, Create, Delete, Read.

Copy the .gitlab-ci.yml file to the root of your repo.
Go in the GitLab project settings, in "Deploy" > "Pages". Activate the service (TBD).
To set up a custom domain name, go to the "Domains & settings" tab of the "Pages" menu. Click the "Add domain" button. Fill in the domain name, and check-enable the "Automatic certificate management". Confirm. You will then need to add two DNS entries : one CNAME (or other, depending on your provider) and one TXT, as described in the page. How to do that will depend on your domain name provider. The page will link to GitLab help pages with more information about the DNS process.
After setting up the DNS, click the refresh button near "Verification status" until it is verified, then click "Save changes".
Then, it is advised to force HTTPS, to uncheck "Use unique domain", and to select your custom domain name as "Primary domain".

Redirect handling (see below) can be done using this tutorial (not tested).

In the Github repo settings, go to "Pages", then enable using "GitHub Actions" instead of "Deploy from a branch".

(TBD)

Copy the .github directory to the root of your repo.

(TBD)

With the standard, Client-Side-Rendered setting of Angular, querying directly a page other than the index of the project will fail, because the Pages server is not told to serve the single html file for all queries.
Reaching a /subpage route is possible, but only by getting to the root page and using the Angular routing to the subpage.
(This is not depicted in this simple project that has a single page.)

A one-size-fits-all solution (for any Pages host) is to opt-in to SSR mode for your Angular project, to not enable SSR for any route (because the Pages server will not do any rendering work for you), but instead set them to SSG, also called Prerendering by Angular, which should create one html file per route and enable direct requests to all routes (including redirect routes).

Specific solutions also exist for Codeberg and GitLab Pages.