Skip to content
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

Closed
msclock opened this issue Mar 14, 2024 · 20 comments
Closed

Invalid user account referred by commits in commits history. #400

msclock opened this issue Mar 14, 2024 · 20 comments

Comments

@msclock
Copy link
Contributor

msclock commented Mar 14, 2024

This email is invalid causing the invalid commits history:

RENOVATE_GIT_AUTHOR: Renovate GitHub Bot <github@renovatebot.com>

image

I consider it could use users.noreply.github.com for Renovate GitHub Bot.

@huxuan
Copy link
Member

huxuan commented Mar 14, 2024

Actually, I created a sub-task Unify git author under #188 but mark it as deprecated mostly because the same behavior is not reproducible to template users since it need a specific user id for the GitHub App as metioned here: https://github.com/orgs/community/discussions/24664. Do you have any ideas to make it happen?

Currently, it shows Co-authored-by: Renovate GitHub Bot <github@renovatebot.com> by default which I think is kindly acceptable.

image

@msclock
Copy link
Contributor Author

msclock commented Mar 14, 2024

Actually, I created a sub-task Unify git author under #188 but mark it as deprecated mostly because the same behavior is not reproducible to template users since it need a specific user id for the GitHub App as metioned here: https://github.com/orgs/community/discussions/24664. Do you have any ideas to make it happen?

Currently, it shows Co-authored-by: Renovate GitHub Bot <github@renovatebot.com> by default which I think is kindly acceptable.

image

The point is the icon shows it is a non-existing user. I consider the noreply email can resolve it🤔

@huxuan
Copy link
Member

huxuan commented Mar 14, 2024

The point is the icon shows it is a non-existing user.

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.

@msclock
Copy link
Contributor Author

msclock commented Mar 14, 2024

I'm sure the email 41898282+<usernanme>@users.noreply.github.com is for GitHub, such as 41898282+Renovate[Bot]@users.noreply.github.com, but not sure what it likes on GitLab. And I'm still digging it.

@huxuan
Copy link
Member

huxuan commented Mar 14, 2024

I'm sure the email 41898282+<usernanme>@users.noreply.github.com is for GitHub, such as 41898282+Renovate[Bot]@users.noreply.github.com, but not sure what it likes on GitLab. And I'm still digging it.

The 41898282 is dynamic I think and it is not the user id for our serious-scaffold-bot[bot]. That is why I mean it is not reproducible to template users. Template users are supposed to create their own GitHub App as the workflow need app id and private key to work. We can definitely hard code it for our projects, but for the template users, that will not work I think.

@huxuan
Copy link
Member

huxuan commented Mar 14, 2024

FYI, the email for serious-scaffold-bot[bot] is 160990600+serious-scaffold-bot[bot]@users.noreply.github.com

image

@msclock
Copy link
Contributor Author

msclock commented Mar 14, 2024

I'm sure the email 41898282+<usernanme>@users.noreply.github.com is for GitHub, such as 41898282+Renovate[Bot]@users.noreply.github.com, but not sure what it likes on GitLab. And I'm still digging it.

The 41898282 is dynamic I think and it is not the user id for our serious-scaffold-bot[bot]. That is why I mean it is not reproducible to template users. Template users are supposed to create their own GitHub App as the workflow need app id and private key to work. We can definitely hard code it for our projects, but for the template users, that will not work I think.

The 41898282 is dynamic I think and it is not the user id for our serious-scaffold-bot[bot]

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:

"41898282+github-actions[bot]@users.noreply.github.com"

The id is essential to prevent confusing two users present in a commit. See actions/checkout#1184

@huxuan
Copy link
Member

huxuan commented Mar 14, 2024

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:

"41898282+github-actions[bot]@users.noreply.github.com"

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.

@huxuan
Copy link
Member

huxuan commented Mar 14, 2024

The id is essential to prevent confusing two users present in a commit. See actions/checkout#1184

AFAIK, the pull request has to be created by the GitHub App. For us, it is 160990600+serious-scaffold-bot[bot]@users.noreply.github.com, set 41898282+github-actions[bot]@users.noreply.github.com as git author for Renovate will still lead to two users.

@msclock
Copy link
Contributor Author

msclock commented Mar 14, 2024

The id is essential to prevent confusing two users present in a commit. See actions/checkout#1184

AFAIK, the pull request has to be created by the GitHub App. For us, it is 160990600+serious-scaffold-bot[bot]@users.noreply.github.com, set 41898282+github-actions[bot]@users.noreply.github.com as git author for Renovate will still lead to two users.

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:

RENOVATE_GIT_AUTHOR: Renovate GitLab Bot <gitlab@renovatebot.com>

It could use the configuration "Renovate GitLab Bot <Renovate GitLab Bot@noreply.gitlab.com>" according to the references:

@msclock
Copy link
Contributor Author

msclock commented Mar 14, 2024

The id is essential to prevent confusing two users present in a commit. See actions/checkout#1184

AFAIK, the pull request has to be created by the GitHub App. For us, it is 160990600+serious-scaffold-bot[bot]@users.noreply.github.com, set 41898282+github-actions[bot]@users.noreply.github.com as git author for Renovate will still lead to two users.

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:

RENOVATE_GIT_AUTHOR: Renovate GitLab Bot <gitlab@renovatebot.com>

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.

@huxuan
Copy link
Member

huxuan commented Mar 14, 2024

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.

@huxuan
Copy link
Member

huxuan commented Mar 14, 2024

And after digging, I'm ensure the internal users on gitlab is a preference. The configuration on GitLab shows here:

RENOVATE_GIT_AUTHOR: Renovate GitLab Bot <gitlab@renovatebot.com>

It could use the configuration "Renovate GitLab Bot <Renovate GitLab Bot@noreply.gitlab.com>" according to the references:

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.

image

All these above have not taken self managed GitLab instance into consideration.

@msclock
Copy link
Contributor Author

msclock commented Mar 14, 2024

And after digging, I'm ensure the internal users on gitlab is a preference. The configuration on GitLab shows here:

RENOVATE_GIT_AUTHOR: Renovate GitLab Bot <gitlab@renovatebot.com>

It could use the configuration "Renovate GitLab Bot <Renovate GitLab Bot@noreply.gitlab.com>" according to the references:

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.

image

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.😅

@huxuan
Copy link
Member

huxuan commented Mar 14, 2024

Good point, so we can have the github@reonvatebot.com and gitlab@renovatebot.com as the default value, since it is configurable via environment variables which is natively supported by renovate.

If I understand correctly, there are several things we can do:

  • Pass through the env RENOVATE_GIT_AUTHOR to containerized jobs in GitHub Actions since GitHub Actions do not native do that.
  • Modify renovate workflow for GitHub Actions and GitLab CI/CD to ensure the fallback logic of default value.
  • Document about the optional configuration RENOVATE_GIT_AUTHOR.
  • Set an organization variable RENOVATE_GIT_AUTHOR to serious-scaffold[bot] <160990600+serious-scaffold[bot]@users.noreply.github.com> for the serious-scaffold GitHub Org.
  • [Optional] Set an group variable RENOVATE_GIT_AUTHOR for the serious-scaffold GitLab Group.

Any comments or suggestions are welcome! :-)

@huxuan
Copy link
Member

huxuan commented Mar 15, 2024

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.

@msclock msclock changed the title Invalid user accout referre by commits in commits history. Invalid user accout referred by commits in commits history. Mar 15, 2024
@msclock
Copy link
Contributor Author

msclock commented Mar 15, 2024

Good point, so we can have the github@reonvatebot.com and gitlab@renovatebot.com as the default value, since it is configurable via environment variables which is natively supported by renovate.

If I understand correctly, there are several things we can do:

  • Pass through the env RENOVATE_GIT_AUTHOR to containerized jobs in GitHub Actions since GitHub Actions do not native do that.
  • Modify renovate workflow for GitHub Actions and GitLab CI/CD to ensure the fallback logic of default value.
  • Document about the optional configuration RENOVATE_GIT_AUTHOR.
  • Set an organization variable RENOVATE_GIT_AUTHOR to serious-scaffold[bot] <160990600+serious-scaffold[bot]@users.noreply.github.com> for the serious-scaffold GitHub Org.
  • [Optional] Set an group variable RENOVATE_GIT_AUTHOR for the serious-scaffold GitLab Group.

Any comments or suggestions are welcome! :-)

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 Renovate[Bot] <project_55404269_bot_4df83adbd4d10149bb058439994b4e6d@noreply.gitlab.com>.🤷‍♂️ I don't know if it's worthy.

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.

@huxuan
Copy link
Member

huxuan commented Mar 15, 2024

🤷‍♂️ I don't know if it's worthy.

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.

Anyway, a ghost user in commits history on GitHub can be prevented by configuring one env.

I may suggest to keep a simple solution: Make the RENOVATE_GIT_AUTHOR configurable and provide a default hard-coded value even if it is a non-existing user.

@msclock
Copy link
Contributor Author

msclock commented Mar 15, 2024

🤷‍♂️ I don't know if it's worthy.

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.

Anyway, a ghost user in commits history on GitHub can be prevented by configuring one env.

I may suggest to keep a simple solution: Make the RENOVATE_GIT_AUTHOR configurable and provide a default hard-coded value even if it is a non-existing user.

Have to agree it.

@msclock
Copy link
Contributor Author

msclock commented Mar 18, 2024

@huxuan As discussed at #416, Besides of the configurable variable RENOVATE_GIT_AUTHOR, a notification should be sent to maintainers.

If I understand correctly, we reach the aggrement the configured RENOVATE_GIT_AUTHOR and a notification is the final solution.

@msclock msclock closed this as completed Mar 18, 2024
@msclock msclock changed the title Invalid user accout referred by commits in commits history. Invalid user account referred by commits in commits history. Mar 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants