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 source checkout steps not rely on hard-coded list of modes #1573

Merged
merged 15 commits into from
Mar 16, 2015

Conversation

seankelly
Copy link
Member

Updated all of the source checkout steps that have a mode option to query their methods to determine the available modes. I dubbed this an "attribute group". This pull request only touches the mode parameter; the method parameter is another that could benefit from this.

Note that I skipped fully converting the p4 step due to a different check of self.mode.

This pull request supersedes #1458.

An "attribute group" is a group of attributes with a common name prefix.
The "mode" attribute group contains two members: full and incremental.
The full and incremental names must have the same "mode_" prefix, making
the method names "mode_full" and "mode_incremental".

The _hasAttrGroupMember and _getAttrGroupMember are the attribute group
equivalents of hasattr and getattr. The _listAttrGroupMembers exists so
options can be returned in error messages to help people know what the
valid options are without checking the docs or source.
Also added validation of the mode when creating the step. No other
validation was added.
The check if self.mode is in possible_modes can be changed but there's
also a check if it's a renderable. That's different from everything else
so I am skipping it until the history is better understood.
@seankelly
Copy link
Member Author

Of course I skipped running all of the tests and see some integration tests failed. It appears the test is wrong because it's using mode="copy" but copy is defined for method, not mode.

Per the documentation, mode is defined to only accept "full" or
"incremental". The method parameter is what accepts "copy". It is an old
commit that set the integration test to use mode="copy" and the CVS step
does little checking.
Returns a list of all members in the attribute group.
"""
from inspect import getmembers, ismethod
methods = getmembers(self, lambda m: ismethod)
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm? Parameter m is not used?

Did you mean to just use ismethod?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops, yeah.

@sa2ajj
Copy link
Contributor

sa2ajj commented Mar 10, 2015

Re method: what do you think about it being a parameter for the mode handling function?

@seankelly
Copy link
Member Author

@sa2ajj Not sure I understand your question. Which function should have a parameter?

@sa2ajj
Copy link
Contributor

sa2ajj commented Mar 11, 2015

currently you have mode_<mode>(self, _) as the handler signature. I wonder what you think about this kind of signature mode_<mode>(self, _, <method>)

@sa2ajj
Copy link
Contributor

sa2ajj commented Mar 11, 2015

As docs states:

mode method

    These two parameters specify the means by which the source is checked out. mode specifies the type of checkout and method tells about the way to implement it.

@seankelly
Copy link
Member Author

My primary objection is the inability to verify method. The two modes accept different methods; that is only partially checked right now. I would like any future changes to method to involve more checking rather than less.

@sa2ajj
Copy link
Contributor

sa2ajj commented Mar 14, 2015

It was just a question.

Anyway, what else needs to be done in this PR so it can land?

@seankelly
Copy link
Member Author

I don't know. You are the one that added the "needs work" label :).

@sa2ajj
Copy link
Contributor

sa2ajj commented Mar 14, 2015

My label was about use of ismethod, but, I believe, I just missed your commit.

I'll have a look now.

@sa2ajj
Copy link
Contributor

sa2ajj commented Mar 14, 2015

Ah, wait, we've been discussing moving that functionality to the base class. Do you think it's for the next PR?

@seankelly
Copy link
Member Author

I think so. The next PR can figure out what to do about method at the same time.

sa2ajj pushed a commit that referenced this pull request Mar 16, 2015
Make source checkout steps not rely on hard-coded list of modes
@sa2ajj sa2ajj merged commit 7c7313d into buildbot:master Mar 16, 2015
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.

3 participants