The error log shows the expected behavior for a lookup when there is no existing target account on the GitLab side. The log event is timestamped 2023-08-03T19:20:22.676942+00:00. The user account at https://gitlab.wikimedia.org/pepepiton was created Aug 1, 2023 10:17pm (timezone uncertain).

The code in question looks like:

def user_lookup(self, uids):
    """Lookup GitHub user data for a list of LDAP uid values."""
    uids = list(filter(None, uids))
    r = {}
    for uid in uids:
        try:
            r[uid] = self.get(
                "users",
                {
                    "provider": settings.GITLAB_PROVIDER,
                    "extern_uid": settings.GITLAB_EXTERN_FORMAT.format(
                        uid
                    ),
                }
            )[0]
        except (APIError, IndexError):
            logger.exception("Failed to lookup user '%s'", uid)
    return r

My hunch is that settings.GITLAB_PROVIDER and/or settings.GITLAB_EXTERN_FORMAT need to be updated as a result of recent activity in T320390: migrate gitlab away from the CAS protocol.

Poking around in the GitLab admin console makes the underlying problem clear. The switch from CAS to OIDC for T320390: migrate gitlab away from the CAS protocol has changed two things about how new accounts need to be looked up:

• The provider identifier is different (a semi-obvious outcome)
• The external user id has changed from the Developer account's uid (shellname) to the account's cn (username)

To unblock @Pepe_piton I did this to create their desired GitHub repo:

• Added myself as a co-maintainer of https://toolsadmin.wikimedia.org/tools/id/paulina
• Clicked "create repository" to make a repo with my Developer account as an owner
• Went to the new https://gitlab.wikimedia.org/toolforge-repos/paulina repo and invited @Pepe_piton to join as an owner
• Removed myself from the maintainers list in Striker

This can be repeated for other tools as needed, but obviously getting Striker updated is a better plan than replacing self-service automation with a fragile manual process.

Change 945880 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):

[labs/striker@master] gitlab: Use LdapUser objects with GitLab integration

https://gerrit.wikimedia.org/r/945880

Change 945880 merged by jenkins-bot:

[labs/striker@master] gitlab: Use LdapUser objects with GitLab integration

https://gerrit.wikimedia.org/r/945880

Change 946601 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):

[operations/puppet@production] striker: Bump container version to 2023-08-07-172444-production

https://gerrit.wikimedia.org/r/946601

Change 946601 merged by Andrew Bogott:

[operations/puppet@production] striker: Bump container version to 2023-08-07-172444-production

https://gerrit.wikimedia.org/r/946601

I was able to use Striker to create https://gitlab.wikimedia.org/toolforge-repos/bd808-test-T343485 with the changes attached to this task now deployed.

The production deployment of Striker is now configured to search for GitLab users associated with "openid_connect" provider keyed by the Developer account cn property (username). Developer accounts which were attached to GitLab via the prior "cas3" provider will not be found until they receive an "openid_connect" provider association. These associations could be back-filled via the GitLab API, but they will happen automatically as folks re-authenticate to GitLab so maybe we do not need an active backfill process?