Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to cache the PipelineTestHelper and dependent libraries #73

Closed
jacobfederer opened this issue Oct 11, 2017 · 4 comments
Closed

Comments

@jacobfederer
Copy link
Contributor

The PipelineTestHelper does a lot of heavy lifting e.g. loading a library from various sources. Since the library content doesn't change during the test execution it would be good to provide a way to cache this helper and it's dependent libraries to speed up the test execution and reducing the I/O effort.

@ozangunalp
Copy link
Contributor

You can call the BasePipelineTest#setUp method in the per class initializer of your test runner.
For example if you are using JUnit you can call the setUp method in your @BeforeClass method as in

class PipelineJobTest extends BasePipelineTest {
    
    @BeforeClass
    void initTests() throws Exception {
        super.setUp();
    }

@jacobfederer
Copy link
Contributor Author

Unfortunately this is not possible since @BeforeClass requires the method to be static. This is caused by the fact that every @Test method will be executed in a separate instance of the referenced test class.

@ssbarnea
Copy link

We have our shared library inside a git repository and we are using the .retriever(GitSource.gitSource(...)) approach to load the shared library... and we have >1300 jobs to tests. If that's true it means that we perform a serious DDOS against git server.

Any workarounds?

@stchar
Copy link
Contributor

stchar commented Dec 6, 2019

I assume this one could be closed.

@stchar stchar closed this as completed Dec 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants