-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat: integration of argoexec rock #10
feat: integration of argoexec rock #10
Conversation
Summary of changes: - Added unit tests. - Added tox.ini to setup unit test environment.
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.
Thanks @i-chvets !
Regarding this PR, and similar ones:
-
I agree on the implementation of the "unit" tests, so having this testing environment and running this kind of checks makes sense. I would rather name this differently, we can call them sanity checks or smoke tests.
-
About this testing environment, I am a bit too concerned with the fact that we have to essentially duplicate the integration testing environment of our charms repos, which means that whatever change we do to workflows in charms repos, we would have to do it in rocks repos.
-
Also about those integration files, I think we are overkilling this by running one integration tests per rock, I'd rather have one integration test at the top level. Essentially what we discussed the other day.
These two last points will really help us prevent technical debt if we nail them correctly.
I will remove |
Summary of changes: - Removed integration env. - Renamed unit to sanity.
@DnPlas Ready for final review. |
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.
This LGTM, but we need to add at least a workflow to ensure this runs as expected. Are you sending another PR for that?
There is a manual testing log. |
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.
Thanks @i-chvets, some comments.
About this:
There is a manual testing log.
For workflow, there will be work done under this issue #11
I think it is important to see this running in the CI as well, not just manual logs. I would suggest that instead of pointing this PR to main
, you point to a feature branch, that way we can merge this PR, send a follow up PR for adding GH workflows and see everything running; otherwise we may run into issues we couldn't catch because we did not see things running.
Also, the issue you are linking in this comment is also linked in the description of the PR.
yield container_name | ||
|
||
try: | ||
subprocess.run(["docker", "rm", container_name], check=True, capture_output=True) |
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.
There is a docker Python SDK, maybe you want to explore that option
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 issue is the size of the dependencies needed for testing. Last time we introduced Chisme for testing and it was rejected, because it was a large dependency. IMO the same rationale applies to this Python Docker SDK.
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 don't think that rationale applies here, as this is in fact, a Python script, and not a command that runs inside a tox file. It's up to you if you want to use the SDK, it was a suggestion to make this script cleaner.
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.
Just a comment on the requirements, other than that LGTM.
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.
Thanks @i-chvets !
Description
Argo exec ROCK
rockcraft.yaml
was updated in #8Changes in this PR are part of this ROCK integration efforts. Another related PR canonical/argo-operators#131
Summary of changes:
requirements*
files.Related issues:
#11
Testing
ROCK building
Unit tests