-
Notifications
You must be signed in to change notification settings - Fork 658
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
add build file for github actions #1622
Conversation
Can one of the admins verify this patch? |
You have done an amazing job! Thank you. |
7218391
to
cb09e02
Compare
1fdd18b
to
52c4203
Compare
This pull request introduces 1 alert and fixes 4 when merging 52c4203 into b9c21c8 - view on LGTM.com new alerts:
fixed alerts:
|
5e68235
to
bf0d644
Compare
@@ -28,7 +28,7 @@ | |||
BASE_DIR = os.path.join(os.path.expanduser("~"), ".indy") | |||
|
|||
tests_require = ['attrs==19.1.0', 'pytest==3.3.1', 'pytest-xdist==1.22.1', 'pytest-forked==0.2', | |||
'python3-indy==1.13.0-dev-1420', 'pytest-asyncio==0.8.0'] | |||
'python3-indy==1.15.0', 'pytest-asyncio==0.8.0'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jovfer, @askolesov, @Toktar, What is your opinion on this? Do you anticipate any unforeseen issues here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's ok if tests are passing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@WadeBarnes, @m00sey I really like this idea. But if we change the dependency here, I suggest changing them in ci/uduntu.dockerfile
to preservation of consistency even if this file will be deprecated soon.
And it's a bit strange if indy-node and indy-plenum will depend on different libindy packages. I guess it's absolutely unimportant because of it's used just for a test environment, but still.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@m00sey, Looking good! Just a few references to update that I can see.
I'd also like to see some documentation indicating which Jenkins pipeline flow(s) this replaces, to make it easier to:
- Identify the Jenkins workflows being replaced.
- Review and compare the Jenkins vs GHA flows to verify everything is covered in the new workflows.
- Decommission the Jenkins workflows when we're satisfied we have equivalent or better GHA flows.
(ci) test this please |
@m00sey, I think some documentation around how to build and manage the |
a06205e
to
5b9a03f
Compare
This pull request introduces 1 alert when merging 5b9a03f into 5a68647 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging fef433c into 5a68647 - view on LGTM.com new alerts:
|
…common/node and lint. Signed-off-by: Kevin Griffin <griffin.kev@gmail.com>
@pytest.mark.auth_framework | ||
def test_auth_rule_add_new_trustee(self, env): | ||
self.runner(AddNewTrusteeTest(env, auth_map.add_new_trustee.get_action_id())) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests for the auth map have already been divided into different ones, since test classes were supplied as parameters to the auth_rule_tests
. Thus, I see no point in making such changes. Personally, it seems to me that now it looks cumbersome, but it's a matter of taste. Another interesting point is that despite the possible improvement in terms of parallelization of tests, their order will be changed. Unfortunately, this can be critical to test passing and lead to unexpected crashes that are nearly impossible to replicate for research. I agree It's a very upset that our tests have this problem, but it's a fact.
Thus, such a change looks ok to me, but in theory it can do some harm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the problem with this test was that the single test, output over 30,000 lines of logs, and is being pushed to the surefire plugin as a single string.
This caused the surefire plugin to break.
The suite has been run many times, without an ordering failure.
However I understand your concern, if we could keep the separate test invocations, but, use pytest.mark to keep order, would that satisfy your concern?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Sure, with a same order it should permanently work.
@@ -28,7 +28,7 @@ | |||
BASE_DIR = os.path.join(os.path.expanduser("~"), ".indy") | |||
|
|||
tests_require = ['attrs==19.1.0', 'pytest==3.3.1', 'pytest-xdist==1.22.1', 'pytest-forked==0.2', | |||
'python3-indy==1.13.0-dev-1420', 'pytest-asyncio==0.8.0'] | |||
'python3-indy==1.15.0', 'pytest-asyncio==0.8.0'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@WadeBarnes, @m00sey I really like this idea. But if we change the dependency here, I suggest changing them in ci/uduntu.dockerfile
to preservation of consistency even if this file will be deprecated soon.
And it's a bit strange if indy-node and indy-plenum will depend on different libindy packages. I guess it's absolutely unimportant because of it's used just for a test environment, but still.
continue-on-error: true | ||
|
||
- name: Run Indy Node ${{ matrix.module }} tests | ||
run: python3 -m pytest -l -m ${{ matrix.module }} -vv --junitxml=test-result-node-${{ matrix.module }}.xml indy_node |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation of parallelizing tests looks pretty cool.
We already have runner.py
for parallelizing tests. It would be great to replace it with something better, but maybe we could do it in the different PRs with adding a GitHub actions to make changes gradually?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how runner.py would parallelize in the same way, given this issues a run command for each permutation in the matrix, runner.py would spawn a single runner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't parallelize in the same way, but runner.py has --test-only-slice
to run only some part of tests dividing them on directories.
Example of using runner.py from indy-plenum CI:
RUSTPYTHONASYNCIODEBUG=0 python runner.py --pytest python -m pytest -l -vv --dir plenum --output test-result-plenum-1.jenkinsubuntu01.txt --test-only-slice 1/3
where 1/3 is a part which we want to launch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That particular runner and usage is already a part of the plenum GHA PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will look into the usage of slice for node.
[for CI] Test this please |
Closed in favor of #1645 |
This PR is superseded by #1645
Jobs for indy-common/node, lint and@pytest.mark
check.In order to parallelize the build, I created a build matrix for each of the "test" packages.Each test is annotated with@pytest.mark<package>
The pytest_checks job returns an array of all found unique decorators and uses that as the build matrix.The build will fail if anytest_
method is missing a mark decorator.This takes the build time from >45 minutes to 12 minutes.Signed-off-by: Kevin Griffin griffin.kev@gmail.com