github-tools / github-tools/github-release-notes

Allow manual changes to persist across --override

Abierto
#139 3 comentarios 1 reacción 0 asignados Ver en GitHub
enhancement
Lenguaje dominante
JavaScript
Estrellas
897
Forks
313
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

Hello,

We've been happily using GREN on an enterprise Github instance to generate release notes based on PR data. We have a use-case where we'd like to add additional, hand-crafted release notes on top of the GREN-generated data that could be persisted even when using `--override`. This would be really useful in adding migration guides for major/breaking releases. We often end up regenerating the GREN release notes in order to add clarifications to PR titles.

Would it be possible to have the GREN-generated data live in a special block that GREN could replace rather than overwriting the entire body?

e.g., for the following release body:

```markdown
// Hand-crafted release notes here
# Migration Guide
...

// Generated GREN data goes here

```

When using `--override`, GREN would only replace/regenerate the contents between the `GREN-BEGIN` and `GREN-END` comment blocks so that any manual additions to the release notes are not overwritten. Since these blocks are just HTML comments, they wouldn't end up visible in the overall release page.

FWIW, here's the `.grenrc` that we're using. Unfortunately I can't share the specific repo data because enterprise 😕

```js
module.exports = {
dataSource: 'prs',
prefix: '',
onlyMilestones: false,
groupBy: {
'💥 Breaking Changes 💥': ['Major (Breaking Change)'],
'✨ Non-Breaking New Features ✨': ['Minor (New Feature)'],
'🛠️ Bug Fixes + Misc 🛠️': ['Patch (Bug Fix)']
},
changelogFilename: 'CHANGELOG.md'
};
```

Thanks!

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

Empieza rastreando el punto de entrada --override y cómo GREN genera el cuerpo de la release, usando como contexto la configuración de ejemplo de .grenrc y CHANGELOG.md. Comprueba cómo se obtiene y reemplaza el contenido existente de la release y, después, define el comportamiento de los marcadores GREN-BEGIN y GREN-END, incluido qué ocurre cuando están ausentes. Se considera terminado cuando el contenido manual permanece intacto y solo se actualiza el bloque generado.

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

Evaluación

Stack tecnológico
javascript
Área
release
Tipo de issue
Nueva funcionalidad
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
35/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.