Re-enable HttpSecurityHeadersTest.UpdateDynamicPKPMaxAge0

Re-enable HttpSecurityHeadersTest.UpdateDynamicPKPMaxAge0

This test was disabled on Windows due to flakiness. I ran it locally & on the try jobs, and neither gave any flakes, therefore, this CL re-enables the test.

BUG=375538
Committed: https://crrev.com/e9d22e0f48e7294f6cda6140a71770efee0b5434
Cr-Commit-Position: refs/heads/master@{#318177}

[hichris123, 2015-02-21 23:44:47]

hichris123@gmail.com changed reviewers:
+ rsleevi@chromium.org

[hichris123, 2015-02-21 23:46:24]

Hi, can you take a look at this CL? It re-enables an HttpSecurityHeadersTest on
Windows that was disabled due to flakiness. It didn't flake locally (with
--gtest_repeat=500), and on the trybots, so I think it's okay to re-enable.

Thanks!

[Ryan Sleevi, 2015-02-23 18:31:03]

On 2015/02/21 23:46:24, hichris123 wrote:
> Hi, can you take a look at this CL? It re-enables an HttpSecurityHeadersTest
on
> Windows that was disabled due to flakiness. It didn't flake locally (with
> --gtest_repeat=500), and on the trybots, so I think it's okay to re-enable.
> 
> Thanks!

Unfortunately, this one has been particularly tricky. It's been reenabled once
or twice in the past after showing no flakes, but then ended up flaking on the
main waterfall.

I previously nack'd a change from Chris to re-enable this test until time was
spent digging in to the root cause. Is there any chance you've done this? I'm
cautious to re-enable it without someone either with a plausible explanation for
why it happened, or without the ability to actively monitor it on the waterfall.
Now that we have the 'always open' tree, it will be less obvious when it's
flaking, but will cause real issues, so I'd like to try to make sure we've got a
good understanding.

[hichris123, 2015-02-24 02:34:43]

On 2015/02/23 18:31:03, Ryan Sleevi wrote:
> On 2015/02/21 23:46:24, hichris123 wrote:
> > Hi, can you take a look at this CL? It re-enables an HttpSecurityHeadersTest
> on
> > Windows that was disabled due to flakiness. It didn't flake locally (with
> > --gtest_repeat=500), and on the trybots, so I think it's okay to re-enable.
> > 
> > Thanks!
> 
> Unfortunately, this one has been particularly tricky. It's been reenabled once
> or twice in the past after showing no flakes, but then ended up flaking on the
> main waterfall.
> 
> I previously nack'd a change from Chris to re-enable this test until time was
> spent digging in to the root cause. Is there any chance you've done this? I'm
> cautious to re-enable it without someone either with a plausible explanation
for
> why it happened, or without the ability to actively monitor it on the
waterfall.
> Now that we have the 'always open' tree, it will be less obvious when it's
> flaking, but will cause real issues, so I'd like to try to make sure we've got
a
> good understanding.

After you mentioned this, I took a look through the flakiness dashboard & the
git log. My theory after looking through that data is that
http://crrev.com/296821 made the test less flaky.

The flakiness dashboard shows HttpSecurityHeadersTest.UpdateDynamicPKPMaxAge0
flaking fairly often with the same

Value of: state.GetDynamicDomainState(domain, &new_dynamic_domain_state2)
Actual: true
Expected: false

stuff up until around the end of September. r296821 landed on September 25th.
After the 25th, only two more flakes with the above signature are in the logs,
one on September 27th, and one on October 2nd.  No more flakes were found with
this signature, which makes me think that r296821 + some other CL made stopped
this test from being flaky. I say some other CL as the last flake with that
signature was October 2nd, and I didn't see a revert of r296821, so something
else must have caused the stoppage of all flakes.

The only other flakes I can find from this test are on the Android builder,
having:

[ERROR:transport_security_state.cc(141)] Rejecting public key chain for domain
docs.google.com. Validated chain: sha1/Pq (truncated by parser)

Which seems possibly like a problem with either docs.google.com or some network
connection.

In regards to the always open tree: I can take a look at the flakiness dashboard
and make sure this test doesn't flake/time out anymore, and report back if it
does.

[Ryan Sleevi, 2015-02-26 00:43:38]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2015-02-26 00:43:38]

lgtm

I'll come after you if it breaks :)

[commit-bot: I haz the power, 2015-02-26 00:44:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/948733002/1

[hichris123, 2015-02-26 00:46:10]

On 2015/02/26 00:43:38, Ryan Sleevi wrote:
> lgtm
> 
> I'll come after you if it breaks :)

Let's hope the test gods are pleased with me. :)

[commit-bot: I haz the power, 2015-02-26 00:46:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-02-26 00:46:41]

Try jobs failed on following builders:
  ios_rel_device_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ng...)
  ios_rel_device_ninja_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)

[hichris123, 2015-02-26 00:48:24]

On 2015/02/26 00:46:41, I haz the power (commit-bot) wrote:
> Try jobs failed on following builders:
>   ios_rel_device_ng on tryserver.chromium.mac (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ng...)
>   ios_rel_device_ninja_ng on tryserver.chromium.mac (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)

Well, guess the ios bots are broken. Looks like troopers are on it.

[hichris123, 2015-02-26 01:44:44]

The CQ bit was checked by hichris123@gmail.com

[commit-bot: I haz the power, 2015-02-26 01:45:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/948733002/1

[commit-bot: I haz the power, 2015-02-26 02:40:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-02-26 02:40:06]

Failed to commit the patch.

[hichris123, 2015-02-26 02:40:51]

The CQ bit was checked by hichris123@gmail.com

[commit-bot: I haz the power, 2015-02-26 02:41:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/948733002/1

[commit-bot: I haz the power, 2015-02-26 02:59:43]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-02-26 03:00:34]

Patchset 1 (id:??) landed as
https://crrev.com/e9d22e0f48e7294f6cda6140a71770efee0b5434
Cr-Commit-Position: refs/heads/master@{#318177}