Support for GitLab tokens

The README suggests that this action only supports username/password or SSH key (+ known_hosts file) for authentication with GitLab.

Is there a reason why it doesn't support GitLab's project access tokens (or indeed GitLab's personal access tokens)? I actually don't fully understand why user+pw would be allowed at all when tokens exist.

ETA: GitLab Token overview page in the GL docs for completeness' sake.

@keikoro you can use gitlab tokens with this Action. When using gitlab tokens for git, you just use the username/password (HTTP basic auth) method. As mentioned in the docs you linked:

Use a project access token to authenticate: [...] With Git, when using HTTP Basic Authentication

For example, if using a personal access token, use your regular username and the personal access token as the password. If using a project access token, you can use any non-blank value as the username and the token value as the password. This is also described in the docs you linked.

When creating the token, you must grant the repository read/write scope.

Thanks, @spyoungtech.

I didn't dig deeper into how authentication works (nor the GitLab docs) and wouldn't have made that connection due to the lack of explicit mentions of tokens in the README + because they are a standalone single identifier in my mind. I.e. I was missing a third config option with only a single variable for the token, as seen in documentation for actions which ingest GitHub PATs.

It might make sense to make this explicit in the README. Or maybe even suggest that over using user/pw for increased security, seeing as tokens have an expiry date (and because it generally feels unwise to me to feed a personal password to a service into another service; I actually wouldn't be surprised if that were officially regarded a violation of the TOS or similar).

Yeah, I agree it would be helpful to have some instructions in the README or separate docs for the most common SCM servers users might want to target. I will work on that.

Sounds great!

I'm not a network whiz, but after poking around various Terms & API docs, I'm assuming using the action with user/pass accesses GitLab via OAuth 2.0 with the Resource owner password credentials flow (?!), which they advise against. What I wanna do is work-related, which got me thinking there are probably people out there who use this with work credentials (e.g. LDAP for self-hosted) without realising that may be in violation of their company policy.

Idk if rewriting the action to only allow tokens going forward would be the way to go, or if there are official GitHub standards/recommendations/guidance for action creators for that sort of thing. I did find my way here because I specifically filtered for GitHub-verified actions, i.e. the "GitHub seal of approval", in any case, so maybe that's something worth considering.

Hmm. The Action is meant to be agnostic of the SCM server. With respect to tokens and SCM servers like GitLab, they accept tokens with git as passwords -- same with GitHub.

Username/password (which could be tokens) and SSH keys is probably what most people are using with git. I'm not sure what other methods we could reasonably support. At the end of the day, git only uses SSH keys and HTTP auth, as far as I'm aware. If your SCM server uses single-sign-on, you use a token or SSH key to access it, generally.

Supporting an OAuth flow is probably out of scope for us, if it were even reasonable/possible. You could perhaps, in principle, use a different Action to obtain your token via OAuth flow, then pass it into this action.

Oh, I wasn't talking about developing a separate workflow, I was more suggesting to discourage use of passwords (over tokens), which could simply mean to rewrite the README to not present them as an option, or to relegate them to a footnote.

GitHub apparently doesn't even allow passwords for HTTPS authentication anymore:

If you authenticate without GitHub CLI, you must authenticate with a personal access token. When Git prompts you for your password, enter your personal access token.
(...)
Password-based authentication for Git has been removed in favor of more secure authentication methods.

and my understanding was that tokens have become the defacto standard either way.

If GitLab doesn't differentiate between tokens and user password on a technical level (seeing as both token + username are required instead of just a token), that sounds more like a quirk on their part.

So even if that means the action cannot be rewritten to only accept one input only, token usage could be (heavily) implied, including e.g. via variable names. If users still wanted to feed regular passwords into the action for whatever reason, they still could (when using GitLab, specifically), but it wouldn't be their first choice.