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

MATLAB testing GitHub Action #145

Closed
jared321 opened this issue Apr 22, 2024 · 3 comments
Closed

MATLAB testing GitHub Action #145

jared321 opened this issue Apr 22, 2024 · 3 comments
Assignees

Comments

@jared321
Copy link
Collaborator

Check to see if MATLAB tests are being automatically run in GitHub actions. If not, then implement this including (hopfully) code coverage.

@jared321 jared321 self-assigned this Apr 22, 2024
@jared321
Copy link
Collaborator Author

jared321 commented Apr 25, 2024

Unfortunately, I believe that this task is intimately tied to the MATLAB path issue #127. I will try to fix up paths as managed by POUNDERS and its tests to get this working.

Requirements

  • Some test cases such as Testpounders just call individual scripts such as test_one_m_pounders. The paths shall be setup automatically within each of these test/example executables so that a user can run MATLAB from the POUNDERS test folder and execute correctly the function by itself with no need for unnecessary additions to the MATLAB path. At the moment, the only necessary cases should be related to BenDFO which is a repo separate from IBDFO and not included in it as a submodule (as MINQ is).
  • If a test/example function sets the path, before terminating it shall reset the path to its state upon entry so that it does not alter the path at the scope of the calling code. At the moment I am not taking this to the logical end where a program should satisfy this requirement if it aborts or terminates early by assert.
  • Users should be able to execute the full test suite from different folders such as pounders, pounders/m, and pounders/m/tests without needing to adjust paths. This implies that paths in the code and tests should not be relative to the current working directory. This requirement is inline with the fact that runtests will run tests only in the current working directory but can be asked to look for tests in subfolders.
    • Because of this requirement, we should be able to run the tests from the root of the repository, which would run tests on all MATLAB subpackages with tests. As a result, there would be a single coverage report for all MATLAB.
  • This implementation shall be such that users can run code coverage associated with the full test suite of each MATLAB subpackage locally and generate an HTML format coverage report. In addition, they should be able to run the full IBCDFO MATLAB test suite and generate a related HTML format report.
  • The MATLAB testing GitHub action shall generate a full POUNDERS test suite HTML format code coverage report and make it available as an artifact. In addition, it shall create a cobertura XML-format coverage report, which can be used with code coverage services such as CodeCov. The action shall publish the report with the code coverage service.
  • (optional) If the Python coverage report can be written in cobertura XML format, then the action shall publish the Python and MATLAB reports with the code coverage simultaneously so that the full code base is grouped as a whole in the service.

jared321 added a commit that referenced this issue Apr 25, 2024
pounders.m and its tests often add folders to the MATLAB path but do so using
relative paths, which can influence from where you can call the code.  The
changes here adopt a different path strategy using paths relative to the file
that is adding to the path.  This is related to Issue #127.  A second goal is
to make it so that users don't have to add too many paths.

Confirmed that the full test suite can be run as detailed in its inline
documentation.  This includes creating an HTML coverage report.  Confirmed that
changes to the path made by tests are not present upon termination.  Ran each
single test individually with a clean MATLAB environment to confirm that they
run through with and only with the documented path requirements.  Confirmed
that they leave the path as found upon entry.
jared321 added a commit that referenced this issue Apr 26, 2024
Changes analogous to those made for POUNDERS in commit ba4fbb1.  Tested in
similar way.  See reference commit's message for more details.  Additionally
confirmed that if I run MATLAB tests with coverage enabled from the root
folder, that all MATLAB tests in IBCDFO were run and all results included in a
single coverage report.
jared321 added a commit that referenced this issue Apr 26, 2024
jared321 added a commit that referenced this issue Apr 26, 2024
jared321 added a commit that referenced this issue Apr 26, 2024
jared321 added a commit that referenced this issue Apr 26, 2024
I am getting a Commit creating failed: ["Service not found: none"] failure in
CodeCov.  Some issues online make it sound like this is due to git not having
the correct safe directory set.  The checkout action is setting safe
directories to both of the repos.  However, these are not being set for the
default folder due to my custom installation of two repos.  Setting the default
workspace as safe to see if this helps.  This is where the reports are and
where code cov is running from (AFAIK).
jared321 added a commit that referenced this issue Apr 26, 2024
@jared321
Copy link
Collaborator Author

I have updated manifold sampling as well so that in theory it could be tested with coverage in the action as well. However, it has an external dependency to the allcomb function in the MathWorks file exchange. To download this for working locally, I had to log in with a MathWorks username/password.

I would like to avoid having a CI action that logs into FileExchange with an account since that is more complex and I prefer to avoid potential security issues. A few other possibilities to explore:

  • MATLAB has a feature called Projects, which appear to be analogous to virtual environments. In particular, you can install setup/teardown scripts that can setup/teardown the environment. See if these can be setup to automatically acquire and download dependencies in FileExchange without an account.
  • MATLAB has a feature called Toolboxes which community developers can setup. They appear to be analogous to Python packages. See if these can be setup to automatically acquire and download dependencies in FileExchange without an account.
  • MATLAB has several GitHub actions that I am using for CI. These already install a version of MATLAB without me inputing any user or license information. It would make sense if these actions could access FileExchange dependencies directly since MathWorks would be able to see what projects are using the files. I need to see if this exists or contact their CI teams to see if it is in the works.

Note that use of Projects/Toolboxes should be investigated simultaneously with the MATLAB path management Issue #127.

jared321 added a commit that referenced this issue Jun 25, 2024
jared321 added a commit that referenced this issue Jun 25, 2024
jared321 added a commit that referenced this issue Jun 25, 2024
jared321 added a commit that referenced this issue Jun 25, 2024
jared321 added a commit that referenced this issue Jun 25, 2024
jared321 added a commit that referenced this issue Jun 25, 2024
jared321 added a commit that referenced this issue Jun 25, 2024
jared321 added a commit that referenced this issue Jun 25, 2024
jared321 added a commit that referenced this issue Jun 25, 2024
jared321 added a commit that referenced this issue Jun 26, 2024
jared321 added a commit that referenced this issue Jun 26, 2024
jared321 added a commit that referenced this issue Jun 26, 2024
I've broken both POUNDERS and manifold sampling tests so that I could see both
fail when running the test from the root of the repo.  However, only the
POUNDERS test should fail in the GH action since the action isn't running any
manifold sampling tests.

THIS SHOULD BE REVERTED!
jared321 added a commit that referenced this issue Jun 26, 2024
jared321 added a commit that referenced this issue Jun 26, 2024
jared321 added a commit that referenced this issue Jun 26, 2024
jared321 added a commit that referenced this issue Jun 26, 2024
jared321 added a commit that referenced this issue Aug 5, 2024
Ran with BenDFO in default location and saw it pass.  Moved clone to different
location and saw it fail.  Set BenDFO env var to wrong path and saw it fail.
Set env var to correct location and saw it pass.
jared321 added a commit that referenced this issue Aug 5, 2024
jared321 added a commit that referenced this issue Aug 20, 2024
Also try to get MATLAB coverage to include all tests.
jared321 added a commit that referenced this issue Aug 21, 2024
In particular, we should not include coverage of the MINQ submodule in coverage.
jared321 added a commit that referenced this issue Aug 21, 2024
Each test log can be quite long.  This makes it easier to review the logs and
quickly zero in on failures.
jared321 added a commit that referenced this issue Sep 9, 2024
If all goes well, this would be addressed in Issue #157.
@jared321
Copy link
Collaborator Author

Merged into develop. Closed.

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

1 participant