Commit graph

5 commits

Author SHA1 Message Date
Baptiste Daroussin 08f5a25d3b ldap: default domain name (#3414)
When the ldap synchronizer is look for an email address and fails at
finding one, it falls back at creating one using "localhost.local"
domain.

This new field makes this domain name configurable.

Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3414
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Baptiste Daroussin <bapt@FreeBSD.org>
Co-committed-by: Baptiste Daroussin <bapt@FreeBSD.org>
2024-04-26 22:38:58 +00:00
Earl Warren 4da76d0e5f Merge pull request 'fix(Dockerfile.rootless): revert to default path for app.ini' (#3363) from gmask/forgejo:fix/container-app-ini-variable into forgejo
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3363
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
2024-04-26 22:36:33 +00:00
Earl Warren a5df622099
docs(release-notes): 7.0.1 2024-04-27 00:31:22 +02:00
Gerard Salvatella dad16cd589 fix(Dockerfile.rootless): revert to default path for app.ini
The current path of the `$GITEA_APP_INI` configuration file makes the
forgejo application reset every time the container is restarted, unless
a specific volume for this file is created. Consider the following:

* This quirk is not documented
* All configuration data resides in `/var/lib/gitea`
* The custom configuration path defaults to `/var/lib/gitea/custom/conf`
  (see `forgejo -h`)
* Containers mounting the volume `-v /foo/bar:/var/lib/gitea` already
  have this file available to modify. Another volume shouldn't be
  required
* Containers using named volumes can use `docker cp` to modify the file
  inside the volume, if desired

For these reasons, it makes more sense to use the default path for
`$GITEA_APP_INI` rather than require users to create a dedicated volume
for the file. Revert it back to its default while maintaining backwards
compatibility (users can update by simply moving the file to the new
path).
2024-04-26 21:30:10 +02:00
Earl Warren 127eff49ee docs(release-notes): split items in files to avoid conflicts (#3452)
I thought there would be conflicts but that they would not be so difficult to manage. Worst idea I had this week. Change to @oliverpool idea instead.

> Instead of documenting the release notes in the issue, why not in the codebase?
>
> For instance in [go](https://cs.opensource.google/go/go/+/master:doc/README.md) there is a `doc/next` folder where you add `<pr-number>.md` files which document each pr.
>
> Before the release, a script takes all those files to generate the changelog.
>
> Having them as a file tracked by git, makes them easy to review and to programmatically handle.

Refs: https://codeberg.org/forgejo/discussions/issues/155#issuecomment-1787013
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3452
Reviewed-by: Gergely Nagy <algernon@noreply.codeberg.org>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
2024-04-26 08:26:33 +00:00