For a (school) project I'm working on we have to develop a medium sized java app that in our case uses javaFX and java CDI dependency injection, we have a scripted jenkins pipeline based on a groovy file that checks every pull request so branches that don't meet quality requirements or fail building can't be merged.
Now we have the issue that only 25% of the developers currently actually run the application to test if their additions work, since the project is in so early stages that a lot of functionality we are currently working on does not get used by the GUI yet. The other 75% of developers use JUnit unit- and intergration-tests to check if their code works. While we could try to say everyone needs to run the actual application before making a pull request to check if there are no runtime errors with java CDI dependency injection. People are people and don't always listen so we quite often get code into develop that succeeds with maven but cant be run due to dependency injection issues.
What is the easiest way to check in the jenkins build that there are no issues with java CDI dependency injection that are going to pop up runtime?
We already use JUnit but not all tests currently use weld injection for test, if its possible to make a single tests that checks all dependency injection issues that would also work instead of a jenkins based solution.
Your CI(continuous integration) approach is good. Testing all PRs is a way to go, you just need to decide what kind of test should be executed. JUnit style, or integration tests? Maybe both?
CDI itself has a deployment validation phase at which it checks, at bootstrap, if things are alright - if beans are passivation capable (those that should), if all declared injection points can be satisfied and so on. This can catch many user-errors before hitting runtime, so just deploying the app shows it. You can, and should, use Arquillian to set up a testing environment much like the actual runtime environment. Note that this validation (no validation in fact) cannot check dynamic resolution errors. E.g. when you use Instance<Object> and then try to resolve a bean that doesn't exist without checking.
If this isn't what you wanted, then you can consider weld-junit extension. This leverages junit (4 or 5) to bootstrap Weld SE container in which you can play around with your beans and test them. Look into READMEs and tests in the projects for examples. This doesn't reflect pure EE environment but is more of a junit style testing with CDI in it and easy to get started with.
Note that with Jenkins, you can setup multiple tasks for each PR. You can make it run all the JUnit tests as well as all the integration (Arquillian) tests for instance.