-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
Invalid user account referred by commits in commits history. #400
Comments
Actually, I created a sub-task Currently, it shows |
The point is the icon shows it is a non-existing user. I consider the noreply email can resolve it🤔 |
Yep, I definitely know that. I mean what exact username and email do you suggest and how to make it reproducible to template users. Same problem also applies to GitLab. |
I'm sure the email |
The |
After some digging, the id is actually the github-actions[bot] api id. See https://github.com/orgs/community/discussions/26560. Maybe it could use as below:
The id is essential to prevent confusing two users present in a commit. See actions/checkout#1184 |
This just change the non-existing user to a different user that does not belong to our projects, and we will still have two authors for each commits generated by Renovate. Does this meet your expectation? Actually, there is no big differencen between them for me. |
AFAIK, the pull request has to be created by the GitHub App. For us, it is |
But it is better than a ghost user presents.🤣 And after digging, I'm ensure the internal users on gitlab is a preference. The configuration on GitLab shows here: ss-python/.gitlab/workflows/renovate.yml Line 19 in d394dcd
It could use the configuration "Renovate GitLab Bot <Renovate GitLab Bot@noreply.gitlab.com>" according to the references:
|
If it's ok, I would like to make a pr to adapt the issue fix. |
It is definitely OK, both for the GitHub and GitLab, I would suggest to have a demo branch to ensure the actual result meets the expectation. Actually, I have tried it on my own, that is why I mark the sub-task as deprecated. |
For GitLab, IMO, it becomes a more complicated problem. Firstly, the template users can use either "Group Access Token", "Project Access Token" or "Personal Access Token". And they will lead to different types of users when creating the merge request, so it will not be easy to have an email for all these situations unless we make all these as template configuration. Moreover, take "Personal Access Token" for example, we need to know the username and email for the account which is used to generate the token, and that may not be the same person who triggers the pipeline. For Group and Project Access Token, we also need to fetch the group id or project id (and the random string, as shown in the documentation you mentioned and the following screenshot) which is simliar to the user id of GitHub App. This will definitely make the whole process more complicated. All these above have not taken self managed GitLab instance into consideration. |
the situation is truly complicated seems what we can do is to proxy the variable RENOVATE_GIT_AUTHOR and require the project/group Maintenainers choose to apply the kind of tokens on gitlab. And the same things seem to do so too.😅 |
Good point, so we can have the If I understand correctly, there are several things we can do:
Any comments or suggestions are welcome! :-) |
Inspired by the previous discussion, I created an issue here: actions/create-github-app-token#114, and according to the suggestions, I made a pull request here: #408 It seems to work but only solve the problem for GitHub App authentication on GitHub Actions. More investigation are needed. |
Anyway, a ghost user in commits history on GitHub can be prevented by configuring one env. On ther other hand, it needs more tricky steps on GitLab. After digging, it seems we can get the email through the GitLab API to do the same things as actions/create-github-app-token for configuring the above env RENOVATE_GIT_AUTHOR as curl --header "PRIVATE-TOKEN: <a token here>" "https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/members" | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 474 100 474 0 0 313 0 0:00:01 0:00:01 --:--:-- 313
[
{
"id": 20313021,
"username": "project_55404269_bot_4df83adbd4d10149bb058439994b4e6d",
"name": "Renovate Token",
"state": "active",
"locked": false,
"avatar_url": "https://secure.gravatar.com/avatar/3c54e83e2bdba6b6a86e5cce0d363718d64eec3154cc5a45a76254255667daac?s=80&d=identicon",
"web_url": "https://gitlab.com/project_55404269_bot_4df83adbd4d10149bb058439994b4e6d",
"access_level": 30,
"created_at": "2024-02-29T05:53:11.437Z",
"expires_at": "2024-03-30",
"membership_state": "active"
}
] a token here can be one of the group/project/personal/api_temporary_created token. |
Yep, that is the key point. As a workflow/pipeline that will regularly triggerred, it might not be worthy to make an additional request for each time. Even the pull request #408 I proposed is optional, it is more like a hack rather than solution.
I may suggest to keep a simple solution: Make the |
Have to agree it. |
This email is invalid causing the invalid commits history:
ss-python/.github/workflows/renovate.yml
Line 11 in d394dcd
I consider it could use users.noreply.github.com for Renovate GitHub Bot.
The text was updated successfully, but these errors were encountered: