I like CI_RELEASE_TOKEN better, it is more descriptive. It is a token, and it will be used by CI to make releases.

CI_PROJECT_PASSWORD is used via the trigger_release CI template, which is used by about 10 different repositories. It will be more work to change all of these.

@amastilovic @Gehel, whatcha think?

The usages of workflow_utils CI templates should be versioned by tag, so we should be able to change the name there to CI_RELEASE_TOKEN without breaking any existent usages. But if/when they upgrade those repos will have to create a new CI_RELEASE_TOKEN variable.

In parent pom.xml, scmUrl is

<scmUrl>scm:git:https://project_${gitlab.projectId}_bot:${env.CI_RELEASE_TOKEN}@gitlab.wikimedia.org/${gitlab.projectPath}/${gitlab.projectName}.git</scmUrl>

What if instead of using env.CI_RELEASE_TOKEN, we make another property for the gitlab project password? All the other variables are also configurable as maven properties directly, why not this one? Then we could circumvent this issue and make CI responsible for setting the correct maven property.

<scmUrl>scm:git:https://project_${gitlab.projectId}_bot:${gitlab.projectPassword}@gitlab.wikimedia.org/${gitlab.projectPath}/${gitlab.projectName}.git</scmUrl>

Then CI could pass either

-Dgitlab.projectPassword=$CI_PROJECT_NAMESPACE

or

-Dgitlab.projectPassword=$CI_RELEASE_TOKEN

Or however the gitlab variable happens to be named.

What if instead of using env.CI_RELEASE_TOKEN, we make another property for the gitlab project password?

IIRC, we encountered an issue where the order in which maven properties are initialized, used, and populated was causing the plugin using scmUrl to never take the correct (overridden) value. I might be wrong though, so the approach you suggested should be tested to see if it works. This would require a NOTE in the README.md or a comment inside the parent pom.xml itself, to warn users that they have to override this value in their .gitlab-ci.yml file.

The other approach would be to change the trigger_release CI template to use CI_RELEASE_TOKEN instead, correct? Would this be possible?

we encountered an issue where the order in which maven properties are initialized, used, and populated was causing the plugin using scmUrl to never take the correct (overridden) value

I made this work specifically by overriding the scmUrl property. So, we know at least that works.

I would be surprised if the other properties that parent pom's scmUrl uses (e.g. gitlab.projectId) work, but a new gitlab.projectPassword one wouldn't.

The other approach would be to change the trigger_release CI template to use CI_RELEASE_TOKEN instead, correct? Would this be possible?

Yup, it would be possible. Usages of trigger_release CI job are (should be) versioned, so we could do this without breaking things, until usages are upgraded to new tag version.

I agree that it would be better if all jobs used the same variable name. We could then standardize the variable name used in the CI templates. So, even if we parameterize the git password via gitlab.projectPassword, we should either change trigger_release to use CI_RELEASE_TOKEN and update docs, or change any current gitlab CI + parent pom release usages to use CI_PROJECT_PASSWORD.

Q: are there any current usages of gitlab CI + parent pom + CI_RELEASE_TOKEN (other than the maven-test-project)?

I would be surprised if the other properties that parent pom's scmUrl uses (e.g. gitlab.projectId) work, but a new gitlab.projectPassword one wouldn't.

Yes overriding the whole of scmUrl works, but the use case I referred to was when you override a Maven property that itself is used in another property (scmUrl in this case). In other words, in a situation like this overriding gitlab.projectPassword probably wouldn't work:

<properties>
        <gitlab.projectPassword>4114</gitlab.projectPassword>
        <gitlab.projectId>1975</gitlab.projectId>
        <gitlab.projectPassword>SET_EXTERNALLY</gitlab.projectPassword>
        <scmUrl>scm:git:https://project_${gitlab.projectId}_bot:${gitlab.projectPassword}@gitlab.wikimedia.org/path/projectName.git</scmUrl>
</properties>

We could then standardize the variable name used in the CI templates.

+1

Q: are there any current usages of gitlab CI + parent pom + CI_RELEASE_TOKEN (other than the maven-test-project)?

Not that I'm aware of. I'm about to port Gobblin to GitLab, so that would be the first project to use it. Based on this alone CI_PROJECT_PASSWORD wins, although CI_RELEASE_TOKEN makes more sense wrt naming itself.

Yes overriding the whole of scmUrl works, but the use case I referred to was when you override a Maven property that itself is used in another property (scmUrl in this case)

Hm. Yeah. Maybe the password variable name wasn't the only reason my stuff wasn't working?

But hm, if I look at the logs from the CI job that failed, it is trying to push to the proper place:

[INFO] Executing: /bin/sh -c cd '/builds/otto/eventutilities' && 'git' 'push' 'https://project_2974_bot:********@gitlab.wikimedia.org/otto/eventutilities.git' 'refs/heads/master:refs/heads/master'

I'm not overriding scmUrl in this run. I am setting e.g. gitlab.projectPath.

Perhaps: should we remove the gitlab specific maven pom properties altogether, and instead just set scmUrl from CI? That might be simpler (and also remove gitlab implementation details from parent pom?)

For the sake of documentation, I wanted to note that the CI_RELEASE_TOKEN variable is not created automagically by GitLab, but it's rather a token created by us, GitLab users, as a "group access token" in a given GitLab repository group. It needs to have the role of a "Maintainer" and scopes "api, write_repository".

Here's example settings for the "maven" repository group.

Indeed! Whichever variable we settle on, we should update docs at https://gitlab.wikimedia.org/repos/data-engineering/workflow_utils#additional-configuration. The docs are explicit, but they are very easy to skip over and forget to do (I have forgotten this step many times).

A screenshot like yours will help :)