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

[Exploration] Simplify testing #544

Closed
wants to merge 16 commits into from

Conversation

frankharkins
Copy link
Member

@frankharkins frankharkins commented Sep 20, 2023

Summary

This explores a simpler testing process. Comments welcome; nothing set in stone yet.

⚠️ After discussing with the team, this is probably not the best approach as:

  1. We don't want to require projects to use tox
  2. Testing actions should live in the projects' repositories so developers have more control over how their tests run.

The solution is probably to provide some support (e.g. a template action) to help developers test in a standardised way, and report back their test results to us (e.g. upload artifacts we can read regularly).

Details and comments

The main changes are:

  1. Remove support for projects with no tox.ini
  2. Drop linting / coverage testing
  3. All testing logic now lives in two GitHub Action files:
    a. All testing logic lives in ecosystem-test-project.yml. Ecosystem developers and Qiskit maintainers should only need to look at this one file.
    b. Another action (ecosystem-batch-test-projects.yml) runs tests on all Ecosystem projects.

See an example run and it's pull request.

@frankharkins frankharkins force-pushed the fh-simplify-testing branch 2 times, most recently from 4e762d7 to c0a8da0 Compare September 21, 2023 13:27
Copy link
Collaborator

@mickahell mickahell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Mainly a comment than a review.)

Hi @frankharkins :) here a bit of my opinion about it, feel free to ignore or tell me if some part aren't relevant :)

  • This looks more than an Ecosystem 2.0 than just a refactoring. Does not be more easy to create a new project more than a branch ? In a new project we should be able to test it and create issue to make it leave and upgrade and not delete everything from the actual version and not be able to come back to the old one.

  • With this solution I'm afraid on a few thinks : We do not control what we are running anymore. If we are not running our own tox, I don't think we should host Actions run of not already validated project.
    We do not launch our own Tox and we will not be able to help and adjust as we do today. Also lot of projects don't have tox file or have tox but don't have Actions to run it in a fresh env and so, help them to create or debugging a tox or Actions is far more complicate than ask them to create an ecosystem.json with few basics commands.

  • If we go full Actions, we will loose the ability to run the Ecosystem from everywhere. The epic [EPIC] Create a GitHub Actions trigger to call wf in another project #490 will not be able to work (without lot of duplication code).

  • In the subject to help project maintainer, I have the feeling people hardly go to read the documentation outside the Readme. I don't see them going to check the actions file to see what is in the wf. And from now on I think the wf is harder to understand than a good doc with just a few commands.

  • I think if we put every logic in the Actions we should have the entire project in the actions and not have a python lib anymore at all. I don't think having an hybrid project would help us or anyone else understanding how does it works and how to improve it. Of course we can still have some scripts but we should delete the python package and have more an architecture around the Actions (example : https://github.com/peter-evans/create-pull-request).

I'm not against this evolution, to be honest when we started the project it was the solution I was thinking we will do at first, but I didn't have in mind what the Ecosystem will be and what it could be few years later.

I still thinks this solution could work :) but we need to put more time in it and not just a refactoring. We can do (almost) what ever we want with Actions (even API), so we should create a real new project and take our time to test it create issue about it.


I hope I wasn't too critical ^^' it's not what I attempted to

Comment on lines +95 to +97
# We upload a JSON artifact so the calling job can read the results.
# This is a bit ugly, but there doesn't seem to be a better way of doing it.
# See https://github.com/orgs/community/discussions/17245 for details.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, using artifact is the classical way to do it :)

Normally you can just add the toml file as artifact and at the end just push it without any special treatment

Comment on lines +91 to +92
tox -epy39
echo "PASS=true" >> $GITHUB_ENV
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm this means test who don't pass will kill the run and not go in the next step and so project will never be update with false test


- name: Add results
run: |
python manager.py add_results_from_artifacts
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do a full action workflow we should delete everything from python lib to not have an hybrid project

matrix:
repo_name: ${{ fromJSON(needs.get_projects.outputs.repo_names) }}
test_type: [standard, stable, development]
uses: frankharkins/ecosystem/.github/workflows/ecosystem-test-project.yml@fh-simplify-testing
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use relatif path to not have future problem with branch and fork ;)


- name: Run tests
run: |
tox -epy39
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happen if the project only run with python 10 or python 8 ?

@mickahell mickahell added question Further information is requested EPIC labels Sep 24, 2023
@frankharkins
Copy link
Member Author

I'm closing this as we've decided not to go down this route.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
EPIC question Further information is requested
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants