What user should I use for PyPi uploads from Twine in a CI system when using Feed API keys?

[hwittenborn]

I've got a feed API key set up for deployments to a PyPi feed, but I can't figure out what user I should be using.

I'm currently using the following command, but all it results in is 403s (${proget_api_key} and ${proget_server} are variables set in my deployment scripts):

twine upload -u api -p "${proget_apt_key}" --repository-url "https://${proget_server}/pypi/python/legacy" dist/*

[hwittenborn]

I had some automated Docker build attempt to get deployed a bit earlier as well, and those appear to have failed from an authentication issue as well. Maybe it's an issue with how I have my key set up?

[Dan_Woolf]

Hi @hwittenborn,

You are using the correct username. When using a username/password with an API key, the username should be api. Would you be able to share your configuration for the API key? It sounds like there is something incorrect in its settings.

If your user account has access to push packages/images to ProGet, could you try using a personal API key? When using a personal API key, you should still use the username api.

Thanks,
Dan

[hwittenborn]

Hi! This is what I have for the key's configuration:

The key is set to allow access to all feeds, so there shouldn't be any issues there.

I also tried the Pesonal format when I was testing it the other day, but I didn't get any luck out of it.

[atripp]

@hwittenborn this can sometimes be tricky to get working...

Did this work in ProGet v5? We made a major change to the api keys in v6, so knowing if it's a regression would help track this down

[hwittenborn]

Yeah, this was all working before in ProGet v5. All of these issues were when I was changing things right after upgrading the other day.

[hwittenborn]

I just went ahead and recreated the key, and everything started working fine. I'm assuming something got messed up during the upgrade then, thought I can't really guarantee anything outside of what's working now.

[atripp]

@hwittenborn thanks for letting me know -- that was going to be my next suggestion. It's very possible the key had an unexpected combination of properties/permissions and that didn't translate to the v6 internal model

But easy enough to recreate in a case like that :)