New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 4 users

Issue metadata

Status: Verified
Closed: Nov 9
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

issue 895274
issue 895360

Sign in to add a comment

Issue 895738: [πŸ“] Access denied to run pinpoint try jobs

Reported by, Oct 16 Project Member

Issue description

I cannot run pinpoint try jobs lately, I did it without troubles in the past.

I sent a mail to blink-dev explaining this:!topic/blink-dev/1YGzRWESzug

Please could we get this fixed somehow? Thanks!

Comment 1 by, Oct 16

Labels: -Pri-3 Pri-2
+sullivan, benjhayden, nednguyen: I'm not sure what the policy is for permissions on the perf dashboard or perf waterfall. Are the perf waterfall results on perf dashboard public or internal?

Pinpoint jobs are restricted to members of chromeperf-access, which is currently Google-internal, since the perf builds and test logs have internal code in them.

Comment 2 by, Oct 17

JFYI, external contributors have been able to run pinpoint try jobs without troubles in the past.
I don't know when this started to change though, my last one that worked was in August.
Also I don't know it it was only available to committers, as I've been a committer for a long time.

In any case a I hope you don't set a policy preventing external contributors to access this, otherwise we are not going to be very helpful in performance related issues.

Comment 3 by, Oct 17

My understanding about the reasons for perf being internal-only:

1) The build logs need to be private, as they could leak information about callstacks in partner code we do not have permission to redistribute. I'm not sure if the links to the build logs would work correctly on pinpoint for external contributors?

2) In the (distant) past we occasionally had unreleased Google hardware on the perf waterfall, and did not want to leak details about the hardware or its performance. It's been many years since this was true, and i've heard of no current plans to do perf testing on unreleased devices. So I don't think this should be an issue.

The policy on the perf dashboard is that all data from the chromium.perf waterfall should be public, but sometimes data is marked internal-only by mistake.

Adding Dirk and Jason who may have some more historical context. My main question is, is it okay for pinpoint to be available to external users as long as 1) and 2) are not leaked? If we are worried about abuse, we could limit to the same set of people who have tryjob access.

Comment 4 by, Oct 17

As long as we're doing official builds, the logs from those builds and tests can't be public. I don't think there's an issue with simply making the results public, though. We might have to walk through the UI and see which things are okay and which aren't.

We likely want a way to run completely internal jobs, and it would be fine to have completely public jobs if they were based on completely public builds.

I'm not worried about abuse per se; as you say, tryjob access is a sufficient gate.

Comment 5 by, Oct 18

I agree with Dirk. I'd also say there are also examples of devices that can't be public still too. Public is fine, still have to be sensitive around Private.

Comment 6 by, Oct 23

But for pinpoint jobs, do they have to be official builds?

Comment 7 by, Oct 31

Blocking: 895274 895360

Comment 8 by, Oct 31

I will change Pinpoint to allow users with tryjob access to kick off jobs.

Comment 6: yes, because the internal code affects the performance of the binaries.

Comment 9 by, Nov 6


Comment 10 by, Nov 6

dtu: Just checking -- has this been enabled for non-Google users with tryjob access yet?

Comment 11 by, Nov 6

+1, it would be really helpful to be able to use pinpoint with a account.

Comment 12 by, Nov 8

Project Member
The following revision refers to this bug:

commit 5d5091665700495b0d212cc504fd48530565eecf
Author: Dave Tu <>
Date: Thu Nov 08 19:59:55 2018

[pinpoint] Let users with tryjob access launch Pinpoint jobs.

Refactor api_request_handler to make it more flexible in the types of
authentication it can do. Instead of _AllowAnonymous(), it has an
overridable method _CheckUser() that checks the user's credentials.
This way, we can override it to accept tryjob users.

Replace PrivilegedPost() and UnprivilegedPost() with just Post().
There were no API handlers that treated privileged and unprivileged
users differently. They only needed to be overridden to do access

Previously there were three tiers of access control:

* Override PrivilegedPost().
* This is now `def _CheckUser(self): self._CheckIsInternalUser()`

* Override UnprivilegedPost() and PrivilegedPost().
* This is now `def _CheckUser(self): self._CheckIsLoggedIn()`

* Override UnprivilegedPost(), PrivilegedPost(), and _AllowAnonymous().
* This is now the default behavior, allowing all users.

Bug:  chromium:895738 
Change-Id: I35a2d9116bd98170ea17caeba9f8756b9304ceb1
Reviewed-by: Juan Antonio Navarro PΓ©rez <>
Commit-Queue: Dave Tu <>


Comment 13 by, Nov 8

Project Member
The following revision refers to this bug:

commit 04baa857df8e2142aa06d5414656df7056feb52b
Author: chromium-autoroll <>
Date: Thu Nov 08 21:44:07 2018

Roll src/third_party/catapult f04a3a61ad90..5d5091665700 (1 commits)

git log f04a3a61ad90..5d5091665700 --date=short --no-merges --format='%ad %ae %s'
2018-11-08 [pinpoint] Let users with tryjob access launch Pinpoint jobs.

Created with:
  gclient setdep -r src/third_party/catapult@5d5091665700

The AutoRoll server is located here:

Documentation for the AutoRoller is here:

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


BUG= chromium:895738

Change-Id: Ie7de7636281943d07faae602d9e54132a5cce7dc
Reviewed-by: chromium-autoroll <>
Commit-Queue: chromium-autoroll <>
Cr-Commit-Position: refs/heads/master@{#606609}

Comment 14 by, Nov 9

Status: Fixed (was: Assigned)
Fixed! All users with tryjob access should be able to kick off jobs. Please reopen if you experience otherwise.

Comment 15 by, Nov 9

Status: Verified (was: Fixed)
Yes this is working, thank you very much!

Comment 16 by, Nov 9

Awesome! Thanks a lot!

Sign in to add a comment