Invalid user account referred by commits in commits history.

[msclock]

This email is invalid causing the invalid commits history:

ss-python/.github/workflows/renovate.yml

Line 11 in d394dcd

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

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

[huxuan]

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.

[msclock]

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.

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

[huxuan]

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]

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]

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]

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

[msclock]

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]

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]

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]

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:

ss-python/.gitlab/workflows/renovate.yml

Line 19 in d394dcd

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:

• https://docs.gitlab.com/ee/development/internal_users.html
• https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#bot-users-for-groups
• https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#bot-users-for-projects.
• https://forum.gitlab.com/t/project-access-tokens-what-is-the-bot-accounts-mail-address-domain-on-gitlab-saas/68165

[msclock]

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:

ss-python/.gitlab/workflows/renovate.yml

Line 19 in d394dcd

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:

• https://docs.gitlab.com/ee/development/internal_users.html
• https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#bot-users-for-groups
• https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#bot-users-for-projects.
• https://forum.gitlab.com/t/project-access-tokens-what-is-the-bot-accounts-mail-address-domain-on-gitlab-saas/68165

If it's ok, I would like to make a pr to adapt the issue fix.

[huxuan]

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]

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

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:

• https://docs.gitlab.com/ee/development/internal_users.html
• https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#bot-users-for-groups
• https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#bot-users-for-projects.
• https://forum.gitlab.com/t/project-access-tokens-what-is-the-bot-accounts-mail-address-domain-on-gitlab-saas/68165

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.

[msclock]

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

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:

• https://docs.gitlab.com/ee/development/internal_users.html
• https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#bot-users-for-groups
• https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#bot-users-for-projects.
• https://forum.gitlab.com/t/project-access-tokens-what-is-the-bot-accounts-mail-address-domain-on-gitlab-saas/68165

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

[huxuan]

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! :-)