Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-25559

Missing hash in client names if ClientNameFormat substitution fails

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      This bug appears in the following conditions:

      • Client name contains ${EXECUTOR_NUMBER} variable

      High-priority issue appears if:

      • Concurrent builds are enabled
      • No NODE_NAME variable in client name
        => Missing hash in Client name => collisions in workspaces on different nodes

        Attachments

          Issue Links

            Activity

            Hide
            rpetti Rob Petti added a comment -

            This is a configuration issue, isn't it? If you don't have the nodename, hostname, or hash in the client name for slaves option, then you will get collisions.

            Show
            rpetti Rob Petti added a comment - This is a configuration issue, isn't it? If you don't have the nodename, hostname, or hash in the client name for slaves option, then you will get collisions.
            Hide
            oleg_nenashev Oleg Nenashev added a comment - - edited

            If PerforceSCM fails to resolve the client name (it happens due to unresolved EXECUTOR_NUMBER), it fall-backs to a default value without a hash.
            Currently, I'm working on this issue. The proper way would be to limit the number of nested recursions in buildEnvVars() by 2 instead of 1 (current implementation)

            private String getEffectiveClientName(@Nonnull AbstractBuild build, @CheckForNull Map<String,String> env) 
                        throws ParameterSubstitutionException, InterruptedException {
                    Node buildNode = build.getBuiltOn();
                    FilePath workspace = build.getWorkspace();
                    String effectiveP4Client = this.p4Client;
                    try {
                        effectiveP4Client = getEffectiveClientName(effectiveP4Client, build);
                    } catch (Exception e) {
                        new StreamTaskListener(System.out).getLogger().println(
                                "Could not get effective client name: " + e.getMessage());
                    }
                    effectiveP4Client = MacroStringHelper.substituteParameters(effectiveP4Client, this, build, env);
                    return effectiveP4Client;
                }
            
            Show
            oleg_nenashev Oleg Nenashev added a comment - - edited If PerforceSCM fails to resolve the client name (it happens due to unresolved EXECUTOR_NUMBER), it fall-backs to a default value without a hash. Currently, I'm working on this issue. The proper way would be to limit the number of nested recursions in buildEnvVars() by 2 instead of 1 (current implementation) private String getEffectiveClientName(@Nonnull AbstractBuild build, @CheckForNull Map<String,String> env) throws ParameterSubstitutionException, InterruptedException { Node buildNode = build.getBuiltOn(); FilePath workspace = build.getWorkspace(); String effectiveP4Client = this.p4Client; try { effectiveP4Client = getEffectiveClientName(effectiveP4Client, build); } catch (Exception e) { new StreamTaskListener(System.out).getLogger().println( "Could not get effective client name: " + e.getMessage()); } effectiveP4Client = MacroStringHelper.substituteParameters(effectiveP4Client, this, build, env); return effectiveP4Client; }
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Rob Petti
            IMO it would be preferable to completely prohibit runtime variables in client names, but it will break many use-cases.
            I'll try to find a convenient solution

            Show
            oleg_nenashev Oleg Nenashev added a comment - Rob Petti IMO it would be preferable to completely prohibit runtime variables in client names, but it will break many use-cases. I'll try to find a convenient solution
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            The issue has been fixed in PR #60 and PR #61
            https://github.com/jenkinsci/perforce-plugin/pull/61
            https://github.com/jenkinsci/perforce-plugin/pull/60

            Automatic SCM Linking does not work

            Show
            oleg_nenashev Oleg Nenashev added a comment - The issue has been fixed in PR #60 and PR #61 https://github.com/jenkinsci/perforce-plugin/pull/61 https://github.com/jenkinsci/perforce-plugin/pull/60 Automatic SCM Linking does not work
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            1.3.31 should resolve the issue.
            // SCM Link bot seems to be dead

            Show
            oleg_nenashev Oleg Nenashev added a comment - 1.3.31 should resolve the issue. // SCM Link bot seems to be dead

              People

              • Assignee:
                oleg_nenashev Oleg Nenashev
                Reporter:
                oleg_nenashev Oleg Nenashev
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: