-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Existing workflow - Failed to collect project info. Please contact our support team for help #174
Comments
Hi @sbulen, Please make sure you're using the latest version of the Action. The easiest way to do it - is to specify the major version only |
The There are two ways to fix this:
|
Thanks, I'll give it a try! |
Were the tokens changed? Do we need to redo the token? |
Update: We have two folders in CrowdIn for our project (SMF_2-1 & SMF_2-1_NEXT). The 2nd folder is used for upcoming release info, for versioning. Having it around allows translations for upcoming releases to proceed in parallel with updates to the current release. The first folder works fine (SMF_2-1). The 2nd folder (SMF_2-1_NEXT) gets the error above. I can reproduce this behavior in my test environment as well. So it's not a token/ownership issue, because the first one works OK now (same project ID, same secret token). But for some reason I cannot update the second folder. |
@sbulen could you please share your Crowdin project ID? It's better to share it by contacting our support team and mentioning this issue as a reference |
I just sent an email to support@crowdin.com that referenced this ticket that provides the project ID. Note that the workflow in question is this one: Note that it attempts to update the 2nd folder (SMF_2-1_NEXT). I have reproduced the same issue on a 2nd (private) CrowdIn project and a 2nd (private) GitHub account. That one also produced an erroneous "You don't have permission ..." error like the one above when trying to update the 2nd folder. So the issue is reproducible. Thanks for your support. |
@sbulen thanks for the details. I checked from our side and it seems like your Crowdin personal access token doesn't have enough scope permissions for fetching all the needed information about the project. Please try creating a token with the following scopes: ![]() |
Thank you for the quick response. I attempted the above in my test environment, and it did not work. As before, it works fine for the first folder (SMF_2-1), but not the second folder (SMF_2-1_NEXT). I still get the "❌ You do not have permission to view/edit project with provided id." error. As both are in the same project, I am using the same project ID and token for both. I repeated the test with a new token that had ALL permissions, and the results were the same. |
@sbulen it's very strange. Could you please try Re-running the WF with the debug logging enabled? |
This is the main part... If you want me to copy the whole thing let me know... (Not sure how safe it is to publish the whole thing...)
|
@sbulen I just investigated the problem in more detail. It looks like there is an issue with the Authorization Token indeed, as I suspected before. Based on the failed "List Branches" API request details, I can say that the token "CROWDIN_API_TOKEN" has no permission to make these requests. Please make sure you're using the right token in your workflow. You can also see the failed requests in your Crowdin project > Tools > API > Calls History. In the log details, you will see the Token Name used for the current request. |
Note we are using a personal access token within the CrowdIn UI, and selecting all permissions. I cannot specify branch/folder there. This has been working for us for a while. Is it possible the personal access token & the api token are now different (since January 2023) & cannot be interchanged anymore? Note I built a parallel test environment, and I am getting the same failure, even with a token with ALL permissions (pic below from test). This new environment fails the same way, so the problem can be reproduced: This action has been running successfully in our production environment for ~2 years. It was implemented in ~3/2021, and ran ok every week thru 1/14/23. The 1/21/23 run was the first time it failed. (Pic below from the production runs.) What changed between 1/14/23 and 1/21/23? |
@sbulen, please make sure that the account under which the token is created has manager permissions for the project |
@sbulen please try creating a token on the project owner's behalf for that environment where the action is failing |
Ok, will do so in our production environment. That token was created by a manager 2 years ago. But note that in my test environment, which has the same error, the token was already created by the owner, as shown in the screenshot above. |
@sbulen the project ID you've already sent to our support team - is this your test environment? |
No, that was production. |
I wonder if project-specific "granular" access is needed now... |
I just attempted creating a new token in test (as owner/manager) with granular access to the project in my test environment. That failed similarly. I sent a note to support with the project ID in test. I don't want to do too much experimentation in production. |
When I sent in the code for my test environment to support, they responded saying that my test run is failing because my free CrowdIn plan only supports one branch. So... To be honest, I don't know if my production plan is failing for the same reason. (I'm a volunteer! Not too familiar with the account details/history...) I asked them if this is the reason for my production run failing as well. |
Closing the loop - yes, recreating the token worked! Thanks, |
Nice to hear that all works fine now :) |
Describe the bug
We have been using this github-action for over two years.
Our crowdin github actions started failing ~4 months ago with the following info. Didn't notice this until today:
![image](https://user-images.githubusercontent.com/23568484/236708612-987ecd06-07ad-45a4-8668-84e41118336f.png)
We tried using a more recent version of the github-action, and are now getting different "No source found" errors:
![image](https://user-images.githubusercontent.com/23568484/236708723-a87d055b-a953-45de-b801-09cc302b59a4.png)
To Reproduce
Steps to reproduce the behavior:
Crowdin GitHub Action configuration
https://github.com/SimpleMachines/SMF/blob/release-2.1/.github/workflows/crowdin_wf.yml
crowdin.yml
file contenthttps://github.com/SimpleMachines/SMF/blob/release-2.1/.github/crowdin.yml
Expected behavior
We expected source strings to be copied to CrowdIn, as in the past, and any new strings to become available for translation. (We do not use the features where translations come back to github.)
The text was updated successfully, but these errors were encountered: