Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Enhancement][CI] Add Branch Protection, Code Analysis and Project board

Abierto
  • ¿Algo no está bien?
#831 20 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
csharp, github, github-actions
Área
ci-cd, devops, tooling

Línea de trabajo

Revisa primero la GitHub Action existente «Build and test» y el área Settings → Code and Automation → Rules → Rulesets. Compara la protección de ramas solicitada, las comprobaciones de Code Scanning y nullability, las ramas de release y el GitHub Project board con las restricciones del repositorio y las decisiones de los maintainers. Se considera terminado cuando haya un conjunto acordado y delimitado de cambios en el repositorio, en lugar de toda la propuesta.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

improvement

Hello @DocSvartz, @stagep, @andrerav,
while reviewing this topic I noticed a few improvements that could help us avoid similar issues in the future. Since I don’t have access to Settings → Code and Automation → Rules → Rulesets, I can’t apply them myself, but I would like to propose the following for your consideration.

1. Branch protection for the default (master) branch

Given that we now have four people who can review pull requests, it would be beneficial to introduce a branch protection rule that:

  • requires all changes to go through a pull request
  • requires at least one approved reviewer before merging into master

This is a common pattern in OSS repositories to ensure code quality and prevent accidental direct commits.

image image

2. Introducing a structured release branch strategy (for backporting)

It might also be helpful to introduce a dedicated release structure like:

  • release
  • release/stable/<version>

This is a common workflow in OSS projects and would allow clean backporting of fixes to already published versions, without forcing users to adopt breaking changes from ongoing development.
This could be valuable for Mapster in the long term, especially regarding stability and predictable package updates.

3. Strengthening CI feedback: code scanning, nullability analysis, and explicit method contracts

In the GitHub Action (“Build and test”), I noticed analyzer annotations such as “possible null reference exception”.
Since unexpected null behavior is undesirable in a published package, I would suggest enabling more comprehensive static analysis and code scanning.

Possible improvements:

  • Enable GitHub Code Scanning (e.g., CodeQL) to detect nullability risks, unsafe patterns, and API-level issues
  • Consider treating selected analyzer warnings as errors or failing CI on critical diagnostics
  • Where applicable, use attributes such as [NotNullIfNotNull], [NotNull], [MaybeNull], etc., to make method contracts explicitly null-aware.

This would allow us to catch potential nullability issues earlier, improve API clarity, and reduce the likelihood of runtime null-related failures for consumers of the package.

→ to implement CI for Code Scanning I would suggest to start with the template provided from GH and maybe someone of you could apply required setup steps that are Mapster specific as there is already a workflow for build & test ?

4. Introducing a GitHub Project for issue tracking and triage

To improve transparency and coordination around ongoing work, it may be beneficial to set up a GitHub Project Board
This would allow us to track, categorize, and triage issues and pull requests more efficiently, while providing a clear overview of priorities, progress, and open tasks.

A project board could help:

  • visualize the current state of issues and PRs
  • support maintainers in triage and planning
  • make contributor workflows more predictable

References you could look into:

It's possible to set up Workflows e.g. along labels that are added so by this we could automate the (base) management for this to not have way more work then it helps us, but we would need to check and improve the available labels then 👍

@andrerav as GitHub preserves the branch protection rules for admin role, I think you will be the one to apply this, if this suggestion would be considerable

Lenguaje dominante
C#
Estrellas
5.2k
Forks
410
Merge medio
1 d 8 h
PR fusionados (30 d)
4

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MapsterMapper/Mapster

Todos los issues de MapsterMapper/Mapster

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.