Allow leading `swift-tools-version` in `Package.swift` for Licensing check
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 45/100
Línea de trabajo
Comienza localizando la comprobación del encabezado de licencia del flujo de trabajo de Soundness y revisando cómo gestiona .licenseignore y los archivos Package.swift. Verifica la comprobación con ejemplos de Package.swift y Package@swift-5.10.swift que incluyan el comentario swift-tools-version, tanto con una línea vacía antes de la licencia como sin ella; la tarea está terminada cuando todas las formas solicitadas pasan sin ignorar los manifiestos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
By convention the first line of a Package.swift manifest is a comment containing the tools version:
"The version is specified on the first line of the manifest with the comment
// swift-tools-version:and the version for the Swift compiler."
Following this convention causes the license header check of the soundness workflow to fail, even if the tools version is followed by a valid license header.
The approach I have seen taken to work around this, is to add the Package.swift file to the .licenseignore file to allow this test to pass.
Since Package.swift files are almost always present in swiftlang repositories, having license checking automatically work with the documented comment on the first line would allow these files to be more easily checked (or checked at all, instead of ignored).
This should also be allowed in version-specific manifest files such as Package@swift-5.10.swift.
Ideally the check would be able to accept both:
- First line is swift-tools-version comment
- License begins on second line
AND
- First line is swift-tools-version comment
- Second line is an empty newline
- License begins on third line
Allowing the tools version to be separated from the license by an empty newline makes it clear the tools version is separate from the license and makes both more easily readable.
- Lenguaje dominante
- Swift
- Estrellas
- 115
- Forks
- 57
- Merge medio
- 1 d 8 h
- PR fusionados (30 d)
- 3
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de swiftlang/github-workflows
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
swiftlang/github-workflows#305 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
swiftlang/github-workflows#261 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
swiftlang/github-workflows#258 · 1 comentario ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
swiftlang/github-workflows#312 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
swiftlang/github-workflows#277 · 1 comentario ·
Todos los issues de swiftlang/github-workflows
Issues similares
-
pending-maintainer-response pending-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
make notarise-dmg notarises whichever dist/ image sorts last, not the one make dmg just built Abiertoarea:build bug good first issue P2
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
uttrflow/uttrflow-swift#1412 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
enhancement
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
-
T-Defect
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
element-hq/element-x-ios#6191 ·