1.4 does not work with project tokens

[tberman]

Orb version

Upgrade from 1.1.2 to 1.4.0

What happened

Wanted the confidence param, tried the upgrade, got back:

master queueable
This build will block until all previous builds complete.
Max Queue Time: 1000000 minutes.
Only blocking execution if running previous jobs on branch: master
Attempting to access CircleCI api. If the build process fails after this step, ensure your CIRCLECI_API_KEY is set.
API access successful
Checking time of workflow: 64c04663-fa40-4a8e-a4ee-75da3bc7bc46
Exited with code exit status 22
CircleCI received exit code 22

Expected behavior

it works! queues!

[eddiewebb]

I added #49 which will add some additional debugging and see if your issue is related to the API token type. Please grab the dev version (eddiewebb/queue@dev:49) from that PR and try it in your project.

[jaylattice]

Hi @eddiewebb @tberman any updates on this? Was the issue due to using the improper token?

[eddiewebb]

@jaylattice can you run the development orb I referenced above?

eddiewebb/queue@dev:49

I need more logs/info to debug what some of you are hitting

[jaylattice]

@eddiewebb No, you're almost certainly correct. The last 4 lines of logs before encountering the StatusCode 22 from your orb was:

API access successful
Checking time of workflow: <wf_id>

Exited with code exit status 22

Tracing this back through your script, the last thing to run was probably: curl -f -s "https://circleci.com/api/v2/workflow/<wf_id>?circle-token=<circle_token>"

So I ran it locally and encountered a curl StatusCode 22; which is caused by an HTTP 404. I verified that the CircleCI API V2 indeed does not work with PROJECT tokens[0]:

Note that project tokens are currently not supported on API v2.

[0] https://circleci.com/docs/api/v2/#authentication

If we still want to do this, we'll try using a personal token. I'll let you know what happens or if we end up not doing it. Thanks a bunch for being SUPER fast with your reply :)

Edit: In the meantime, I created a new issue https://github.com/eddiewebb/circleci-queue/issues/58 that might fix other bugs too? Idk.

[eddiewebb]

Thanks for confirming Jay. I updated the issue title to reflect. I see the value in fixing this, but without v2 api supporting project tokens it gets much less accurate in queuing orders and statuses.

[jaylattice]

without v2 api supporting project tokens, it gets much less accurate in queuing orders and statuses

@eddiewebb Not sure I understand why. Isn't the fix to just use the v1.1 API instead, or to just use personal tokens? Why would using personal tokens make it less accurate in queueing orders?

[eddiewebb]

That is the fix. I recommend personal tokens above, but for teams that may not be ideal.

1.1api doesn't expose pipeline level data, which is the only true source of circles triggering timestamp.

I don't have the power to change the apis, so it's personal tokens or bust for now.

On Fri, Mar 27, 2020, 3:37 PM jaylattice notifications@github.com wrote:

without v2 api supporting project tokens, it gets much less accurate in queuing orders and statuses

@eddiewebb https://github.com/eddiewebb Not sure I understand why. Isn't the fix to just use the v1.1 API instead, or to just use personal tokens? Why would using personal tokens make it less accurate in queueing orders?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eddiewebb/circleci-queue/issues/48#issuecomment-605281511, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIEWSQTQW5XION7GNBO6WLRJT57JANCNFSM4J7BGKSQ .

[jaylattice]

Alright, that makes sense. Feel free to close my other ticket.

On Fri, Mar 27, 2020 at 5:45 PM Eddie Webb notifications@github.com wrote:

That is the fix. I recommend personal tokens above, but for teams that may not be ideal.

1.1api doesn't expose pipeline level data, which is the only true source of circles triggering timestamp.

I don't have the power to change the apis, so it's personal tokens or bust for now.

On Fri, Mar 27, 2020, 3:37 PM jaylattice notifications@github.com wrote:

without v2 api supporting project tokens, it gets much less accurate in queuing orders and statuses

@eddiewebb https://github.com/eddiewebb Not sure I understand why. Isn't the fix to just use the v1.1 API instead, or to just use personal tokens? Why would using personal tokens make it less accurate in queueing orders?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/eddiewebb/circleci-queue/issues/48#issuecomment-605281511 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABIEWSQTQW5XION7GNBO6WLRJT57JANCNFSM4J7BGKSQ

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eddiewebb/circleci-queue/issues/48#issuecomment-605369546, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMODO3DN6M3LZEREUJOZMY3RJVCBJANCNFSM4J7BGKSQ .

--

Jay Patel

Software Engineer

lattice.com http://www.lattice.com/ | jay@lattice.com

[maylortaylor]

My company is looking at Circle CI for our CI/CD needs but only allowing Personal API Tokens seems very limiting to us. We have multiple people on our team and if one leaves, we dont want to go change all of our repos.

Allowing a Project-level API Token to trigger a build is all we need. What can we do to have this flexibility and still use Circle CI.

[henrik]

@maylortaylor We have an "Foo Company Integrations" GitHub account that we use for stuff like this. So it would have the "personal" token, and all devs have access to this account via our shared 1Password vault.