a year ago
My build step fails during the npm install. The server is unable to get access to my private Github repository's package. I have set a .npmrc file at the root level of my project that should access the environment variable (that I have put into the Railway variables) that holds my Github PAT that should give the server access to the package. Instead, it fails saying that it doesn't have read:packages permission.
My deploymentId is cf40b30e-6ae8-4008-8bd7-297e77d8bbb9.
0 Replies
a year ago
nixpacks does not support pulling private packages, you would need to write a Dockerfile to solve this issue.
a year ago
no prob
Actually - still seeing the same issue even though I have since migrated to using Dockerfiles for deployment. The token is definitely the correct token - is there any reason why this still would have a permission error?
Deployment Id: 95f94276-0229-4131-8169-05c486642495
a year ago
Can you send the Dockerfile?
a year ago
is GITHUB_READ_PACKAGES the only variable you need to auth to github?
//npm.pkg.github.com/:authToken=${GITHUBREAD_PACKAGES}
registry=https://npm.pkg.github.com/reviva-main
-> all I have in the .npmrc file
a year ago
whats the current error you get?
npm ERR! code E403
31.21 npm ERR! 403 403 Forbidden - GET https://npm.pkg.github.com/@reviva-main/reviva-common - Permission permissiondenied: readpackage
31.21 npm ERR! 403 In most cases, you or one of your dependencies are requesting
31.21 npm ERR! 403 a package version that is forbidden by your security policy, or
31.21 npm ERR! 403 on a server you do not have access to.
31.21
31.21 npm ERR! A complete log of this run can be found in: /root/.npm/logs/2024-04-23T222359162Z-debug-0.log
a year ago
seems like simply setting a GITHUB_READ_PACKAGES is not all you need to do and there are more steps needed that you are leaving out
hm - so it works fine locally with the same token. Is there a resource that you're looking at that suggests otherwise?
a year ago
no resources, I've never done this before, but on account of it not working means something wasn't done right 😆
right.. is there a way to get access to the complete log? There may be a trace id that I could send to the Github support team
a year ago
the only accessible logs are what you see in the build and deploy logs
a year ago
I'm positive you aren't the first to try to write a Dockerfile that uses packages from a private repo so there has to be examples you can look at
a year ago
you sent me logs a few messages ago?
a year ago
I don't know what you mean by that
a year ago
ah that, no there's no way to access that