Tox Generic / Unit Test

[cts-zeero]

Purpose

Adding python tox generic and python tox unit test step implementer.

Breaking?

No

Integration Testing

Tested a local python tox test environment command execution to confirm the tests ran succesfully against the tox.ini configuration file.

• Tox generic makes no assumption about installed packages or commands defined in the tox.ini. It simply calls the target tox environment defined in the tox_env configuration parameter and executes the associated .ini config.
• The tox unit-test step implementer defaults to test for the tox_env parameter.

[codecov]

Codecov Report

Merging #219 (7e076ba) into main (14ee488) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main      #219   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           84        87    +3     
  Lines         3479      3556   +77     
=========================================
+ Hits          3479      3556   +77     

Flag	Coverage Δ
pytests	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...tep_runner/step_implementers/shared/tox_generic.py	100.00% <100.00%> (ø)
...tep_runner/step_implementers/unit_test/__init__.py	100.00% <100.00%> (ø)
...tep_runner/step_implementers/unit_test/tox_test.py	100.00% <100.00%> (ø)
src/ploigos_step_runner/utils/tox.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 14ee488...7e076ba. Read the comment docs.

[itewk]

@cts-zeero can you collapse down your commits and get rid of the merge commits for a clean history?

[itewk]

Tox generic makes no assumption about installed packages or commands defined in the tox.ini. It simply calls the target tox environment defined in the tox_env configuration parameter and executes the associated .ini config.

does that mean as part of the ToxGeneric we should also be calling some other target to install dependecies? or have another StepImplmenter specific for caling a target for installing dependeices?, or assume the target will install its own dependieces?

[cts-zeero]

Working on the rebase now.

Tox generic will call tox with the -e <env> argument so any dependencies defined inside of the tox.ini should be installed during the tox environment setup.

As far as tox itself, that would have to be installed in the step container before executing the step.

[itewk]

Tox generic will call tox with the -e argument so any dependencies defined inside of the tox.ini should be installed during the tox environment setup.

k

As far as tox itself, that would have to be installed in the step container before executing the step.

@cts-zeero so sounds like we need a ploigos-tool-python container image with tox in it then in our ploigos-containers project.

[cts-zeero]

I think the container image will be needed for sure.

[cts-zeero]

For whatever reason this commit <ff2c29b1fd128d70875ca66316e96a000c91259c> keeps complaining when I try to rebase.

The previous cherry-pick is now empty, possibly due to conflict resolution.

[cts-zeero]

Do you want me to squash all the way back to <f12384d2b0ce78a98e37c7bf185ed720b9da10c6>?

f12384d?

[itewk]

@cts-zeero i know its annoying, but when all else fails with re-basing, can you just copy the 7 changed files out to a temp dir, re-create the branch from main, and then copy the files back to create a new clean commit?

[cts-zeero]

I am getting test failures after directly cloning the main branch.

========================================================================================= FAILURES =========================================================================================
___________________________________________________________ TestStepWorkflowResultTest.test_write_results_to_json_file_exception ___________________________________________________________

self = <test_workflow_result.TestStepWorkflowResultTest testMethod=test_write_results_to_json_file_exception>

>   ???
E   AssertionError: RuntimeError not raised

/workspaces/ploigos-step-runner/tests/results/test_workflow_result.py:785: AssertionError
___________________________________________________________ TestStepWorkflowResultTest.test_write_results_to_yml_file_exception ____________________________________________________________

self = <test_workflow_result.TestStepWorkflowResultTest testMethod=test_write_results_to_yml_file_exception>

>   ???
E   AssertionError: RuntimeError not raised

/workspaces/ploigos-step-runner/tests/results/test_workflow_result.py:543: AssertionError

[itewk]

@cts-zeero hrmm. i just pulled main and ran the tests and they are all passing. Did you try runing the tests against main without your changes to verify they run clean on your system as is right now?

[cts-zeero]

Yea I cloned without changes and tested. Let me check something else.

I doubt the tests are broken, given that they would have failed the PR checks. I wanted to make sure it was just me first.

[itewk]

@cts-zeero heyo. so i pulled your branch down locally, re-based on the latest from main and then pushed up to my own branch (https://github.com/itewk/ploigos-step-runner/tree/feature/tox). Tests and linting all pass locally for me.

I can either re-create this PR from my fork/branch, or you can pull my fork/branch and reset your fork/branch to my rebase, or you can do the same rebase.

[cts-zeero]

Lets use your branch since it is already working. I will update my main fork once we merge it in.

[itewk]

this will be replaced by #223

[itewk]

merged #223