Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

271
Visualizações
¿Cómo marcar el escenario como inestable si la condición de Powershell resulta verdadera?

Tengo una solución .Net 5 y construyo los proyectos con análisis de estilo de código. Cada regla violada da como resultado una advertencia. Pero el comando de compilación sale con el código 0.

Creé un archivo .gitlab-ci.yml que debería marcar la canalización como inestable si se lanzan advertencias de compilación.

 image: mcr.microsoft.com/dotnet/sdk:5.0 stages: - build - unit-tests build: stage: build script: - |- dotnet build --output build -consoleloggerparameters:"Summary;Verbosity=normal" -m -p:"WarnLevel=5;EnforceCodeStyleInBuild=true" -t:"clean,build" -fl1 "/flp1:warningsonly"; if ((!$LASTEXITCODE) -and (Get-Content "msbuild1.log")) { # >>> mark stage as unstable here <<< } artifacts: paths: - build unit-tests: stage: unit-tests script: - dotnet test --no-build --output build dependencies: - build

La etapa en sí pasa pero esperaba que pase con un estado inestable (por las advertencias), lamentablemente es verde.

Una mala solución sería agregar el indicador -warnaserror para el comando de compilación y usar allow_failure: true para el escenario. Esto pondría el escenario en un estado inestable, pero las próximas etapas fallarían debido a la falta de construcción.

Entonces, ¿cuál sería la forma correcta de verificar si el comando de compilación terminó con advertencias para marcar el escenario como inestable?

over 4 years ago · Santiago Trujillo
2 Respostas
Responde à pergunta

0

Traté de agregar una code-quality etapa adicional que funciona perfectamente bien para mí

 image: mcr.microsoft.com/dotnet/sdk:5.0 stages: - build - code-quality - unit-tests build: stage: build script: - dotnet build --output build artifacts: paths: - build code-quality: stage: code-quality script: - |- dotnet tool install -g dotnet-format; dotnet format -wsa --check --verbosity diagnostic; if ($LASTEXITCODE) { exit 1; } allow_failure: true dependencies: - build unit-tests: stage: unit-tests script: - dotnet test --no-build --output build dependencies: - build

Lo único que me pregunto es por qué tengo que verificar el código de salida. Si falla el formato dotnet, sale con el código 2. ¿Pero Gitlab parece verificar solo el código de salida 0 o 1? Porque el código de error 2 da como resultado el éxito. Es por eso que tengo que verificarlo manualmente.

Si alguien sabe cómo mejorar esto, por favor hágamelo saber!

over 4 years ago · Santiago Trujillo Relatório

0

No estoy muy seguro de si esto sería lo que está buscando, pero tengo entendido que sus unit-tests dependen de la code-quality anterior o del paso de build (o ambos). En este caso, modifica su paso unit-tests para que sea algo como:

 unit-tests: stage: unit-tests script: - dotnet test --no-build --output build # replace 'dependencies' with 'needs' needs: - job: build artifacts: true - job: code-quality

Las consecuencias serían que si la compilación falla, su canalización fallará, en caso de que falle el paso code-quality , aún podrá ejecutar las unit-tests , excepto cuando el paso de prueba dependa de los artefactos del paso de calidad del código.

over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda