> I think running all of them for now is the best way. If the runtime on
Travis becomes unbearable we can look into solutions then.
Smoke tests were created at the behest of developers for precisely this
situation. This line of code:
py.test -v --color=yes --pyargs pulp_smash.tests.pulp3
...can
Are we running only a subset? I think currently we run all of them on
Travis before each merge.
I think running all of them for now is the best way. If the runtime on
Travis becomes unbearable we can look into solutions then.
On Tue, Apr 17, 2018 at 4:22 PM, Daniel Alley
On Tue, Apr 17, 2018 at 8:32 AM, David Davis wrote:
> A couple things. First, we’re only running pulpcore and pulp_file tests
> against pulpcore PRs. Also, we’re not running all pulp-smash tests for each
> PR—only a certain subset labeled as "smoke tests". That said, we’ll
A couple things. First, we’re only running pulpcore and pulp_file tests
against pulpcore PRs. Also, we’re not running all pulp-smash tests for each
PR—only a certain subset labeled as "smoke tests". That said, we’ll still
want to keep an eye on pulp-smash tests over time to make sure it doesn’t
"The plan for quality involves the continuous delivery of Pulp 3 where both
unit and integration are run with each PR and prior to each release to PyPI"
My concern about the above statement is that as the number of tests
increases, the time it will take to run the pulp-smash integration suite
The documentation has been updated[0].
[0]
https://docs.pulpproject.org/en/3.0/nightly/contributing/continuous_integration.html
On Fri, Apr 6, 2018 at 2:52 PM, Dennis Kliban wrote:
> I have updated the redmine issue[0] to include a page in the contributors
> guide on
Dennis,
Thanks for putting this together. I don't see any responses on this thread
and take that to mean there were no concerns about this proposal.
Would this process/responsibility change need to go anywhere? (Side
questions, was this technically a PUP?)
"author of the PR would need to be