Fail build when unittests fail for PRs#60
Conversation
BertScholten
force-pushed
the
fail_pr_build_when_tests_fail
branch
from
49ad3b6 to
068ce32
Compare
|
Apparantly the service modules were never tested with PR builds. Not sure if this is the correct change (I think putting the service jars in Nexus makes sense, but there might be other reasons why this shouldn't be done?), or if we should change the action to not use |
|
The reasoning was that only the client parts are used by other projects. The service parts are never used by others. As a little bonus this also allows us to do the Docker part before the Maven Publish part, so that if the Docker images fail to build, it won't have pushed the client libraries. |
|
Bump.. Should we merge as is or fix it? |
|
Let's fix it properly. 2 step approach sounds correct, I think we'd want to use a different maven profile for PR builds than |
BertScholten
force-pushed
the
fail_pr_build_when_tests_fail
branch
2 times, most recently
from
5f5fa71 to
8bf9908
Compare
.github/workflows/on-pull_request-opened-synchronize-reopened.yml
Outdated
Show resolved
Hide resolved
Not sure what the idea was behind not publishing the service and its dependencies, but it's causing the code not to be compiled/tested when building the PR. And these should be published to nexus anyway I think?
it was removed with f17cdc8, which seemed a bit weird? Assume it was just supposed to remove just the docker build part.
Also not specifying a profile, as search does not have a 'deploy' profile anyway.
BertScholten
force-pushed
the
fail_pr_build_when_tests_fail
branch
from
8bf9908 to
50902d0
Compare
Jenkins already builds on PR, no real need to do it twice. Though jenkins isn't publicly reachable, so not as transparent for people outside AERIUS, it's also not like we had people outside contributing.
|
3 participants
Be more strict on failing tests for PRs, to avoid missing a failing test before merging.