User used instead of Username for the Bitbucket Server authentication

[dcoraboeuf]

When using the Bitbucket Server (Stash) plugin:

scms:
  repository:
    kind: stash
    spec:
       url: https://bitbucket.example.org
       owner: PRJ
       repository: sample
       username: some-user
       token: some-token

this fails with "authentication required".

By specifying both username and user, the SCM can be cloned. This PR will fix this.

scms:
  repository:
    kind: stash
    spec:
       url: https://bitbucket.example.org
       owner: PRJ
       repository: sample
       username: some-user
       user: some-user
       token: some-token

[olblak]

Thanks for the PR, I am curious as I am pretty sure it used to work, I am wondering if I introduced that regression

[olblak]

@naimo84 Could you confirm you are also affected by this issue?

[olblak]

@dcoraboeuf thanks for your PR, after a quick look at the code it seems you are right \

updatecli/pkg/plugins/resources/stash/client/main.go

Line 20 in 4c6e2d5

Username string `yaml:",omitempty"`

[olblak]

This means that Gitlab and Gitea are both wrong :D

[olblak]

I find the user vs username quite confusing and I must admit I am often wrong.
The intend is to differentiate the git user versus the username used to authenticate on api (if needed).

[dcoraboeuf]

I find the user vs username quite confusing and I must admit I am often wrong. The intend is to differentiate the git user versus the username used to authenticate on api (if needed).

Easy to be confused by that. If I understood the code correctly though, username should be used for authentication against the Bitbucket Server API and not user (which is used for the commit signature together with email)?

[olblak]

Easy to be confused by that. If I understood the code correctly though, username should be used for authentication against the Bitbucket Server API and not user (which is used for the commit signature together with email)?

Yes that's exactly that

[olblak]

This PR is a bug fix that introduce a breaking change, I would like to do the same for the Gitlab and Gitea resource with a big warning for the next release

[dduportal]

This PR is a bug fix that introduce a breaking change, I would like to do the same for the Gitlab and Gitea resource with a big warning for the next release

+1: this PR should only be merged with a warning message.
I'm not sure if a "fallback" behavior could be done to avoid breaking existing configurations?
Otherwise let's plan to release this with a log message (+ a carefully crafted changelog)

[olblak]

This PR is a bug fix that introduce a breaking change, I would like to do the same for the Gitlab and Gitea resource with a big warning for the next release

+1: this PR should only be merged with a warning message. I'm not sure if a "fallback" behavior could be done to avoid breaking existing configurations? Otherwise let's plan to release this with a log message (+ a carefully crafted changelog)

I've been wondering if it was possible but I think it will be even more confusing

[olblak]

After looking at the code, this won't be a "breaking" change because we currently have to specify both user and username anyway

At the moment user is used for

• git clone
• git commit

and username is used for

• git push
• git checkout
• git push --tags

After this change, user will only be used by git commit