Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

@bgrant0607 PTAL

fieldPath: fieldPath? Really?

@smarterclayton Really.

Ugh.... wasn't that supposed to be reference fieldPath?

@smarterclayton I had thought @bgrant0607 explicitly wanted fieldPath for both. I'll go back and read through the comments again.

@smarterclayton #6739 (comment)

Hrm, I think seeing it in the actual API makes me think it was a bad decision. We can revisit later but I'm not a fan of redundant redundancy.

----- Original Message -----

@smarterclayton
#6739 (comment)

---

Reply to this email directly or view it on GitHub:
#7592 (comment)

@smarterclayton Yeah, I felt the same thing -- I'm trying to think of better names but coming up empty.

ObjectFieldSelector.FieldPath needs to stay FieldPath in order to match ObjectReference.

Other possibilities for EnvVarSource.FieldPath:

• Field
• FieldRef
• ObjectFieldRef

FieldRef makes the most sense to me.

Agreed

On May 1, 2015, at 8:26 PM, Brian Grant notifications@github.com wrote:

FieldRef makes the most sense to me.

—
Reply to this email directly or view it on GitHub.

Alrighty, I will change it.
On Fri, May 1, 2015 at 8:29 PM Clayton Coleman notifications@github.com
wrote:

Agreed

On May 1, 2015, at 8:26 PM, Brian Grant notifications@github.com
wrote:

FieldRef makes the most sense to me.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#7592 (comment)
.

@smarterclayton updated, PTAL

LGTM, may need to regenerate docs as well (put them in their own commit).

@smarterclayton I got no real diffs from regenerating

Sorry, I meant swagger, not docs.

@smarterclayton It's a lot of changes for the swagger spec -- do you want it in this PR?

Separate commit.

LGTM

Will merge on green travis

I recommend postponing the swagger updates to a separate PR. Unrelated changes are causing the validation test to fail when the swagger is updated.

@bgrant0607 fine with me.

On Mon, May 4, 2015 at 6:00 PM, Brian Grant notifications@github.com
wrote:

I recommend postponing the swagger updates to a separate PR. Unrelated
changes are causing the validation test to fail when the swagger is updated.

—
Reply to this email directly or view it on GitHub
#7592 (comment)
.

It doesn't matter because travis will never give you a green

What do you mean @smarterclayton? Shippable failed on this PR, apparently due to the swagger update.

cc @nikhiljindal

It's been waiting for a good 4-5 hours to start

Also, the generated swagger still contains fieldPath rather than fieldRef.

CLAs look good, thanks!

@bgrant0607 Removed the swagger commit, I will look into that separately as a follow-up.

LGTM

It looks like we need to update go-restful again to get the *int64 fix:
emicklei/go-restful@63c8f08

Rerunning Shippable.