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

Make Pulp Smash test MODIFIED issues #54

Closed
wants to merge 1 commit into from
Closed

Make Pulp Smash test MODIFIED issues #54

wants to merge 1 commit into from

Conversation

Ichimonji10
Copy link
Contributor

The bug_is_testable and bug_is_untestable functions talk to the pulp.plan.io bug tracker, inspect the state of a named bug and then tell the caller whether the named bug is testable or not. Make these functions treat MODIFIED issues as test-worthy. Both before and after this patch:

============  ==================
Pulp Version  Test Suite Results
============  ==================
2.6           OK (skipped=13)
2.7           OK (skipped=12)
dev           OK (skipped=12)
============  ==================

@Ichimonji10
Copy link
Contributor Author

@bmbouter @dkliban @rbarlow and others: is this change appropriate? One or two people on IRC asked for this change.

@bowlofeggs
Copy link

@Ichimonji10 Modified means that the change is in our git repos, but that it is not in an RPM build. I think this make the questions maybe a little complicated. Does pulp-smash know if it is testing a source install (like the dev environment) vs. an RPM install? Because a MODIFIED bug will be fixed in a source install and be broken in the RPM install. I know that sounds complicated, but it's our way of tracking WHERE a bug fix can be expected to be found.\

Would it be crazy to make pulp-smash aware of whether it is testing a source install vs. an RPM install, and let it dynamically choose whether MODIFIED or ON_QA is appropriate?

If the goal is to only test source installs then I think this change is good.

@dkliban
Copy link
Member

dkliban commented Dec 16, 2015

@rbarlow I think that it is safe to say that pulp-smash will be running on an RPM install that contains the fix. We currently build RPMs nightly, deploy Pulp using those RPMs, run pulp-smash. So if something is in MODIFIED state then it should be in the newly build RPM.

@Ichimonji10
Copy link
Contributor Author

Does pulp-smash know if it is testing a source install (like the dev environment) vs. an RPM install?

Nope. You can tell Pulp Smash which version of Pulp it is testing, but you cannot at this time tell it whether it's testing a source or RPM install.

@Ichimonji10
Copy link
Contributor Author

Because a MODIFIED bug will be fixed in a source install and be broken in the RPM install.

Gotcha. And then an ON_QA bug will be fixed in both a source and RPM install.

@bmbouter
Copy link
Member

If we wait until the issue is at ON_QA there will be a multi-week, perhaps multi-month delay in tests becoming enabled. We really need them enabled with MODIFIED.

I think dkliban's comment suggests that it will work in both RPM based installs and source installs since RPM based installs are rebuilt from source nightly.

The `bug_is_testable` and `bug_is_untestable` functions talk to the pulp.plan.io
bug tracker, inspect the state of a named bug and then tell the caller whether
the named bug is testable or not. Make these functions treat MODIFIED issues as
test-worthy, instead of waiting until issues enter the ON_QA state. This allows
Pulp Smash to test fixes that have been implemented and are available through
source installs and the nightly RPM builds.

Both before and after this patch:

    ============  ==================
    Pulp Version  Test Suite Results
    ============  ==================
    2.6           OK (skipped=13)
    2.7           OK (skipped=12)
    dev           OK (skipped=12)
    ============  ==================
@Ichimonji10 Ichimonji10 deleted the modified branch December 16, 2015 23:39
@Ichimonji10
Copy link
Contributor Author

Merged as 8ce9eda

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

Successfully merging this pull request may close these issues.

4 participants