---
[en-US]: Update version and versioning format for DATAWARE Forge
- In the Makefile, a new versioning format has been added for DATAWARE Forge, now using version 25.1.0321 with compatibility for Forgejo 10.0.0-13 and Gitea 1.22.0.
- The Makefile.datawareforge.version.mk file was created to centralize and define the version variables for DATAWARE Forge, including the major, minor, and build version numbers.
- The `DATAWARE_FORGE_VERSION` variable has been defined to compose the product version in the format `25.1.0321+forgejo-10.0.0-13+gitea-1.22.0`.
- The README.md file has been updated to reflect the new product version, detailing the version number and compatible components.
- The version is now displayed clearly, including compatibility with Forgejo and Gitea to enhance understanding.
These changes ensure that the product's versioning is aligned with the new DATAWARE Forge identification structure, maintaining clarity about compatible versions and the build format.
---
[pt-BR]: Atualiza versão e formato de versionamento do DATAWARE Forge
- No arquivo Makefile, foi adicionado um novo formato de versionamento para o DATAWARE Forge, agora utilizando a versão 25.1.0321 com compatibilidade com Forgejo 10.0.0-13 e Gitea 1.22.0.
- O Makefile.datawareforge.version.mk foi criado para centralizar e definir as variáveis de versão do DATAWARE Forge, incluindo os números de versão principal (major), secundária (minor) e de build.
- A variável `DATAWARE_FORGE_VERSION` foi definida para compor a versão do produto no formato `25.1.0321+forgejo-10.0.0-13+gitea-1.22.0`.
- No arquivo README.md, a seção de versão foi atualizada para refletir a nova versão do produto, detalhando o número de versão e os componentes compatíveis.
- A versão agora é exibida de forma clara, incluindo a compatibilidade com o Forgejo e o Gitea para facilitar a compreensão.
Essas mudanças garantem que o versionamento do produto esteja de acordo com a nova estrutura de identificação do DATAWARE Forge, mantendo clareza sobre as versões compatíveis e o formato de build.
---
Marcos A. Lucas <mlucas@dataware.com.br>
**[PT-BR]**
- Atualiza o Makefile para alterar mensagens de requisitos de Go, Git LFS e Node.js, substituindo "Forgejo" por "DATAWARE Forge".
- Modifica scripts e comandos (ex.: merge de locales, ações, certificados, documentação e CLI) para refletir a nova identidade, mudando nomes e descrições de "Forgejo" para "DATAWARE Forge".
- Altera mensagens de log, headers, textos de erro e avisos em vários módulos (actions, hooks, keys, doctor, web, etc.) para garantir consistência com a marca DATAWARE.
- Atualiza templates e arquivos de configuração (ex.: app.example.ini, init scripts, etc.) para usar "DATAWARE Forge" em textos, placeholders e URLs.
- Ajusta testes e mensagens em módulos de autenticação, webhook, indexador, banco de dados e outros, substituindo referências a "Forgejo" por "DATAWARE Forge".
Estas alterações consolidam o rebranding white-label para DATAWARE Forge, mantendo a integridade do código original e preparando o sistema para uso interno e posterior distribuição.
**[EN]**
- Updated the Makefile to change messages regarding Go, Git LFS, and Node.js requirements, replacing "Forgejo" with "DATAWARE Forge".
- Modified scripts and commands (e.g., locale merge, actions, certificate generation, documentation, and CLI) to reflect the new identity by renaming and updating descriptions from "Forgejo" to "DATAWARE Forge".
- Changed log messages, headers, error texts, and warnings in various modules (actions, hooks, keys, doctor, web, etc.) to ensure consistency with the DATAWARE brand.
- Updated templates and configuration files (e.g., app.example.ini, init scripts, etc.) to use "DATAWARE Forge" in texts, placeholders, and URLs.
- Adjusted tests and messages in modules for authentication, webhooks, indexing, database, and others, replacing references from "Forgejo" to "DATAWARE Forge".
These changes consolidate the white-label rebranding for DATAWARE Forge, preserving the original code integrity while preparing the system for internal use and future distribution.
Marcos A. Lucas <mlucas@dataware.com.br>
---------------------------------------------------------------
[PT-BR]
Este commit implementa a transição do rebranding de Forgejo/Gitea para DATAWARE Forge, realizando as seguintes alterações:
- Atualização dos arquivos de configuração de ambiente e containers:
- `.devcontainer/devcontainer.json` e `.gitpod.yml` agora exibem "DATAWARE Forge" em vez de "Gitea" ou "Forgejo".
- Ajustes no Makefile:
- Alteração do branding do Swagger para "DATAWARE Forge API" e modificação da mensagem de licença.
- Modificações em comandos e scripts:
- Em `cmd/generate.go`, a descrição foi atualizada para refletir "DATAWARE Forge's secrets/keys/tokens".
- Em `contrib/environment-to-ini/environment-to-ini.go`, foram adicionadas novas variantes de prefixos de variáveis de ambiente para suportar diversas formas (DATAWARE, DW, etc.).
- Inclusão de novos arquivos de serviço e init scripts:
- Novos scripts de init para Debian e Ubuntu foram adicionados, com descrições e comandos atualizados para DATAWARE Forge.
- Alterações em diversas partes do código (modelos, rotas, serviços, testes e webhooks):
- Todas as referências, mensagens, headers (ex.: X-DatawareForge-OTP, X-DatawareForge-Object-Type), endpoints, logs e textos foram atualizadas para substituir “Gitea” ou “Forgejo” por “DATAWARE Forge”.
- Ajustes em mensagens de erro e instruções de configuração (app.ini, README, etc.) para refletir a nova identidade.
- Atualizações em arquivos de configuração e templates (ex.: `custom/conf/app.example.ini`) para alinhar com a nova marca DATAWARE Forge.
Essas alterações consolidam a personalização white-label, garantindo a integridade do código original enquanto preparam o sistema para uso interno e futura distribuição a clientes.
---------------------------------------------------------------
[EN]
This commit implements a rebranding from Forgejo/Gitea to DATAWARE Forge, making the following changes:
- Updated environment and container configuration files:
- `.devcontainer/devcontainer.json` and `.gitpod.yml` now display "DATAWARE Forge" instead of "Gitea" or "Forgejo".
- Makefile adjustments:
- Changed the Swagger branding to "DATAWARE Forge API" and updated the license message.
- Modifications in commands and scripts:
- In `cmd/generate.go`, the usage description now reflects "DATAWARE Forge's secrets/keys/tokens".
- In `contrib/environment-to-ini/environment-to-ini.go`, new environment variable prefix variants have been added (DATAWARE, DW, etc.).
- Inclusion of new service and init scripts:
- New init scripts for Debian and Ubuntu have been added, with updated descriptions and commands for DATAWARE Forge.
- Changes across various parts of the code (models, routers, services, tests, and webhooks):
- All references, messages, headers (e.g., X-DatawareForge-OTP, X-DatawareForge-Object-Type), endpoints, logs, and texts have been updated to replace “Gitea”/“Forgejo” with “DATAWARE Forge”.
- Adjustments in error messages and configuration instructions (app.ini, README, etc.) to align with the new identity.
- Updates in configuration files and templates (e.g., `custom/conf/app.example.ini`) to match the new DATAWARE Forge branding.
These changes consolidate the white-label customization, ensuring the original code’s integrity while preparing the system for internal use and future client distribution.
Marcos A. Lucas <mlucas@dataware.com.br>
- Add a new setting `EMAIL_DOMAIN_BLOCK_DISPOSABLE` that will append a list of
domains that are known for being used by temporary or disposable email
services.
- Add a utility to automatically download and format the list of domains from
the disposable-email-domains project on github.
(https://github.com/disposable-email-domains/disposable-email-domains)
license: CC0 1.0 Universal (CC0 1.0) [Public Domain]
from README:
"""
This repo contains a list of disposable and temporary email address domains often used to register dummy users in order to spam or abuse some services.
We cannot guarantee all of these can still be considered disposable but we do basic checking so chances are they were disposable at one point in time.
"""
Goals:
- speedup
- less flakiness
- best practices and more use
- documentation
config:
- sync ports in Makefile and playwright config
(otherwise, some tests fail locally because they assert the full URL including the (wrong) port)
- even more generous timeouts
- limit workers to one again (because I finally understand how
Playwright works)
- allow nested functions to group them together with the related test
all:
- deprecate waitForLoadState('networkidle')
- it is discouraged as per https://playwright.dev/docs/api/class-page#page-wait-for-load-state
- I could not find a usage that seems to require it actually (see
added documentation in README)
- adding an exception should be made explicitly
- it does not do what you might expect anyway in most cases
- only log in when necessary
webauthn:
- verify that login is possible after disabling key
- otherwise, the cleanup was not necessary after the previous refactor to create a fresh user each
issue-sidebar / WIP toggle:
- split into smaller chunks
- restore original state first
- add missed assertion to fix race condition (not waiting
before state was reached)
- explicitly toggle the state to detect mismatch earlier
issue-sidebar / labels:
- restore original state first
- better waiting for background request
- Do not require minio for mariadb docker.
- Do not require elasticsearch for mysql.
- Fix postgress password parameter.
- Add the multistatement query for mysql (this is not optimal but adding
Makefile code doesn't seem to work really well either)
- Add a new script that proccess the localization files and verify that
they only contain HTML according to our strictly defined rules.
- This should make adding malicious HTML near-impossible.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/5703
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Make the big move to Eslint flat config format. The outcome of Eslint
still should be the same, but some things has changed:
- `eslint-plugin-github` is dropped, flat configs have been out for a
while and most eslint plugins support it, but for no reason and no
activity in sight this plugin is likely not going to support flat config
for a while and to avoid other plugins not being able to update (as they
are requiring flat configs) drop the github rules.
- Nested configs don't work properly and are unified into the root
eslint config, this unification did cause some conflicts and thats why
the `import-x` is in a seperate 'group' to exclude targeting Vue files.
- The `eslint-plugin-i` is deprecated and `esplint-plugin-import-x` is
its succesor which has better support for flat configs, the same rules
are still applied.
The majority of the flat config was generated by
`@eslint/migrate-config` tool.
gotestsum [1] is a tool that brings sanity to human-powered
analysis of test results, supporting handy summaries of results
and more.
This implementation allows for the use of `USE_GOTESTSUM=yes`
to switch the implementation from raw `go test` to `gotestsum`.
It also gives general flexibility in choice of go tests runner.
The PREFIX-SUFFIX play is needed for compiled tests and may
be subject to modification depending on the outcome of #5248
[1] https://pkg.go.dev/gotest.tools/gotestsum
This is a step towards making Forgejo's binaries (the one listed in the
release tab) reproducible.
In order to make the actual binary reproducible, we have to ensure that
the release workflow has the correct configuration to produce such
reproducible binaries. The release workflow currently uses the
Dockerfile to produce binaries, as this is one of the easiest ways to do
cross-compiling for Go binaries with CGO enabled (due to SQLite). In the
Dockerfile, two new arguments are being given to the build command.
`-trimpath` ensures that the workpath directory doesn't get included in
the binary; this means that file names (such as for panics) are
relative (to the workpath) and not absolute, which shouldn't impact
debugging. `-buildid=` is added to the linker flag; it sets the BuildID
of the Go linker to be empty; the `-buildid` hashes the input actions
and output content; these vary from build to build for unknown reasons,
but likely because of the involvement of temporary file names, this
doesn't have any effect on the behavior of the resulting binary.
The Makefile receives a new command, `reproduce-build#$VERSION` which
can be used by people to produce a reproducible Forgejo binary of a
particular release; it roughly does what the release workflow also does.
Build the Dockerfile and extract the Forgejo binary from it. This
doesn't allow to produce a reproducible version for every release, only
for those that include this patch, as it needs to call the makefile of
that version in order to make a reproducible binary.
There's one thing left to do: the Dockerfile pins the Go version to a
minor level and not to a patch level. This means that if a new Go patch
version is released, that will be used instead and will result in a
different binary that isn't bit to bit the same as the one that Forgejo
has released.
