Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

badges are not applied because 'current' repository detection is wrong when loading library dynamically #1569

Open
aubertaa opened this issue Aug 31, 2023 · 1 comment
Labels
bug For changelog: Minor bug. Will be listed after features

Comments

@aubertaa
Copy link

aubertaa commented Aug 31, 2023

Jenkins and plugins versions report

Environment
Jenkins: 2.387.3
gitlab-plugin:1.7.14

What Operating System are you using (both controller, and any agents involved in the problem)?

Linux Ubuntu 20.04

Reproduction steps

In a multibranch pipeline:

  1. Load a library dynamically with library method
  2. checkout git repository with jenkins git method
  3. try to set badges on repository using gitlabBuilds and/or gitlabCommitStatus
//configure gitlab connection
properties([
    gitLabConnection("mygitlab"),
])

//dynamic load of library ! (this is different from @Library)
library "mylibraryidentifier@master"

node() {
    
    //checkout my product's repository => doing this should result in setting commit status badges on this repository/commit on further operations
    git credentialsId: 'xxxxxxxxxxxxxxxxxxx', url: "https://my_gitlab_repository.git", branch: env.BRANCH_NAME

    gitlabBuilds(builds: ["test1","test2","test3"]) {  //should set 'pending' commit status badges in my_gitlab_repository
        sleep 5

        gitlabCommitStatus(name: 'test1') { //should update 'test1' commit status badge in my_gitlab_repository
            echo 'this is pre-build stage'
            sleep 5
        }

        gitlabCommitStatus(name: 'test2') { //should update 'test2' commit status badge in my_gitlab_repository
            echo 'this is build stage'
            sleep 5
        }
    }
}

Expected Results

All commit statuses should be successfully set on previously checked out repository : "my_gitlab_repository"

Actual Results

this is my library repository that receives all commit statuses

Anything else?

  • Disabling the library dynamic load instruction gets back to the expected behavior.
  • It seems that there is a wrong consideration of multiple repositories (library repository + my_gitlab_repository) in the plugin when defining the target of commit statuses
    • this is confirmed by plugin logs showing that considered url is not the expected one 'my_gitlab_repository':
Aug 31, 2023 11:29:14 AM INFO com.dabsquared.gitlabjenkins.util.CommitStatusUpdater retrieveGitlabProjectIds
Retrieving gitlab project ids

Aug 31, 2023 11:29:14 AM INFO com.dabsquared.gitlabjenkins.util.CommitStatusUpdater addGitLabBranchBuild
Retrieving the gitlab project id from remote url [my library repository url]

I suspect that it could be related to this code, not considering the right SCM information:

final SCMRevisionAction scmRevisionAction = build.getAction(SCMRevisionAction.class);

As stated in #899 (comment), a workaround is available to enforce gitlabCommitStatus to the right repository but this workaround is unfortunately not possible on gitlabBuilds method.

(It would also be acceptable to be able to set specific target repository when calling 'gitlabBuilds' as a workaround)

Thanks for your help on this.

@aubertaa aubertaa added the bug For changelog: Minor bug. Will be listed after features label Aug 31, 2023
@aubertaa
Copy link
Author

aubertaa commented Aug 31, 2023

I investigated a bit more, indeed the getAction method returns 'one' of the repositories, i don't know what the criterion is. Here is the return from an admin console script in jenkins, showing the returns for the job where statuses are not applied on the right repository:

All actions from getActions() are:

[org.jenkinsci.plugins.workflow.cps.replay.ReplayFlowFactoryAction@4513008f, hudson.model.CauseAction@22b63a2d,
hudson.model.ParametersAction@4545e099, jenkins.scm.api.SCMRevisionAction@5de53613,
jenkins.scm.api.SCMRevisionAction@184da4d0, jenkins.scm.api.SCMRevisionAction@2d51f625,
jenkins.scm.api.SCMRevisionAction@34e51065, jenkins.scm.api.SCMRevisionAction@6fde564b,
jenkins.scm.api.SCMRevisionAction@4fab7fa6, jenkins.scm.api.SCMRevisionAction@1c4c0c5b,
jenkins.scm.api.SCMRevisionAction@342a4428, jenkins.scm.api.SCMRevisionAction@3649e75e,
jenkins.metrics.impl.TimeInQueueAction@6b26e8e5, jenkins.scm.api.SCMRevisionAction@25d56d87,
org.jenkinsci.plugins.workflow.cps.EnvActionImpl@2deb49fc, org.jenkinsci.plugins.workflow.libs.LibrariesAction@5f37edcc,
com.cloudbees.plugins.credentials.builds.CredentialsParameterBinder@32006f22,
hudson.plugins.git.util.BuildData@34f20be2[scmName=,remoteUrls=[git@mygitlab_url:cicd/internal-tools-ci-utils.git],buildsByBranchName={letest=Build #49 of Revision 1edb4611d31e7c446c1474d861f8a7a80d252f71 (letest)},lastBuild=Build #49 of Revision 1edb4611d31e7c446c1474d861f8a7a80d252f71 (letest)],
MultiSCMRevisionState{git git@mygitlab_url:cicd/internal-tools-ci-utils.git=hudson.scm.SCMRevisionState$None@234544f7, git https://mygitlab_url/cicd/dummy_internal_tool.git=hudson.scm.SCMRevisionState$None@234544f7},
hudson.plugins.git.util.BuildData@d3e8a857[scmName=,remoteUrls=[https://mygitlab_url/cicd/dummy_internal_tool.git],buildsByBranchName={refs/remotes/origin/letest=Build #49 of Revision 9a121ac02d3e75596c9e6d0757d395f9f23bcb6f (refs/remotes/origin/letest)},lastBuild=Build #49 of Revision 9a121ac02d3e75596c9e6d0757d395f9f23bcb6f (refs/remotes/origin/letest)],
com.dabsquared.gitlabjenkins.workflow.PendingBuildsAction@72464c7d,
jenkins.metrics.impl.SubTaskTimeInQueueAction@229835d0
]

Single action from getAction(hudson.plugins.git.util.BuildData.class) is:

hudson.plugins.git.util.BuildData@34f20be2[scmName=,remoteUrls=[git@mygitlab_url:cicd/internal-tools-ci-utils.git],buildsByBranchName={letest=Build #49 of Revision 1edb4611d31e7c446c1474d861f8a7a80d252f71 (letest)},lastBuild=Build #49 of Revision 1edb4611d31e7c446c1474d861f8a7a80d252f71 (letest)]

We can see indeed that only one of the two hudson.plugins.git.util.BuildData si returned and no luck, it's not the one i expected (last checked out repository). Jenkins javadoc indeed states that it returns "first instance to be found" (cf https://javadoc.jenkins-ci.org/hudson/model/Actionable.html#getAction(java.lang.Class) )

All present items should be considered or a way to specify the repository should be added to all methods present on this page (to allow each one to choose what he wants): https://www.jenkins.io/doc/pipeline/steps/gitlab-plugin/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug For changelog: Minor bug. Will be listed after features
Projects
None yet
Development

No branches or pull requests

1 participant