"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
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
+1 to option 2.
David
On Tue, Apr 17, 2018 at 9:39 AM, Brian Bouterse wrote:
> I believe option 2 would be a good improvement for Pulp's API. It would
> resolve the current problem that a RepoVersion and/or a Publication can be
> created in multiple places in the REST API.
On Fri, Apr 13, 2018 at 4:40 PM, Dennis Kliban wrote:
> On Fri, Apr 13, 2018 at 1:25 PM, Patrick Creech
> wrote:
>
>> Pulp,
>>
>> So, while working on the packaging work, I figured it be nice to start
>> talking about release process expectations around
I believe option 2 would be a good improvement for Pulp's API. It would
resolve the current problem that a RepoVersion and/or a Publication can be
created in multiple places in the REST API.
On Fri, Apr 13, 2018 at 3:55 PM, Jeff Ortel wrote:
>
>
> On 04/12/2018 04:49 PM,
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
>
> *1. Core endpoints do not delegate/redirect to plugins.*
> - POST to /RepositoryVersion/ is removed.
> - POST to /Publications/ (stays gone)
> - Plugins provide endpoints for sync and other to create new
> repository versions.
> - Plugins provide endpoints for creating
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