search

dedis / cothority

Scalable collective authority
Other
425 stars 106 forks source link

Put test in lint_build #2421

Closed ineiti closed 3 years ago

ineiti commented 3 years ago

Using on:workflow_run puts the result of the workflow in the master-branch, which makes it impossible to use the results of test.yaml in the requirement of the PR.

This PR creates a monster-workflow lint_build_test to avoid that problem.

tharvik commented 3 years ago

Again on this barrier job, did you consider using needs: [javascript, golang, pre-commit] inplace of needs: lint-build?

sonarcloud[bot] commented 3 years ago

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

ineiti commented 3 years ago

Again on this barrier job, did you consider using needs: [javascript, golang, pre-commit] inplace of needs: lint-build?

Yes, I did, and I thought it's nicer with a barrier - it represents better the difference between the lint-build that contains 3 jobs, and the test job... But if you convince @cgrigis it's cleaner with a needs: [...], I'm OK with it...

cgrigis commented 3 years ago

Yes, I did, and I thought it's nicer with a barrier - it represents better the difference between the lint-build that contains 3 jobs, and the test job... But if you convince @cgrigis it's cleaner with a needs: [...], I'm OK with it...

I lean towards needs: lint-build, as it is used 4 times and thus avoids repetition and eases maintenance. It is unfortunate that this requires a whole job though, it would be much simpler to allow a variable, but that does not appear possible. :-( What's one more VM spawn anyway? ;-)