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

Expose private tokens from email-ext

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      In github-pullrequest-plugin i experimentally created content expansion with private email-ext tokens, this functionality looks generic so we want introduce it in https://github.com/jenkinsci/github-plugin/pull/100 but using hack for macros extraction is not good.

      Many times people mentioned that this tokens should be extracted from email-ext.

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          integer Kanstantsin Shautsou added a comment -

          Atm moment i see the next variants:

          1. Review private tokens and define whether they can be removed at all, i.e. BUILD_NUMBER seems duplicates existed job variables
          2. migrate generic tokens like BUILD_LOG_EXCERPT to token-macro-plugin
          3. keep as is some tokens that depends on global Email-Ext hudsonUrl configuration it impossible to make them generic
          4. keep as is JELLY_SCRIPT and SCRIPT. Both depends on templates in JENKINS_HOME and SCRIPT is a bad name and may conflict with some cases. So create new GROOVY_SCRIPT token somewhere (even separate plugin because it will depends on config-file-provider?).

          That should keep backward compatibility, GROOVY_SCRIPT may obsolete SCRIPT (using files in JENKINS_HOME imho is bad design future) and provide other plugins ability to use this tokens without having dependency on email-ext-plugin

          Show
          integer Kanstantsin Shautsou added a comment - Atm moment i see the next variants: Review private tokens and define whether they can be removed at all, i.e. BUILD_NUMBER seems duplicates existed job variables migrate generic tokens like BUILD_LOG_EXCERPT to token-macro-plugin keep as is some tokens that depends on global Email-Ext hudsonUrl configuration it impossible to make them generic keep as is JELLY_SCRIPT and SCRIPT . Both depends on templates in JENKINS_HOME and SCRIPT is a bad name and may conflict with some cases. So create new GROOVY_SCRIPT token somewhere (even separate plugin because it will depends on config-file-provider?). That should keep backward compatibility, GROOVY_SCRIPT may obsolete SCRIPT (using files in JENKINS_HOME imho is bad design future) and provide other plugins ability to use this tokens without having dependency on email-ext-plugin
          Hide
          Permalink
          integer Kanstantsin Shautsou added a comment -

          For 1. only 2 tokens can be deleted https://github.com/jenkinsci/email-ext-plugin/pull/110

          Show
          integer Kanstantsin Shautsou added a comment - For 1. only 2 tokens can be deleted https://github.com/jenkinsci/email-ext-plugin/pull/110
          Hide
          Permalink
          integer Kanstantsin Shautsou added a comment - - edited

          For 2. Need to be checked whether they tied to html generation

          • BuildLogContent - no html, just print log lines
          • BUILD_LOG_EXCERPT - no html, just print log lines
          • BuildLogMultilineRegexContent – supports html optionally
          • BuildLogRegexContent - supports html optionally
          • BuildURLContent - generic
          • JobDescriptionContent - generic
          • CauseContent - generic, but token name CAUSE potentially bad
          • WorkspaceFileContent - looks generic

          For 3. Not generic tokens:

          • ChangesSinceLast* - depends on email-ext (getPreviousBuild probably can be extracted), one named CHANGES, other CHANGES*
          • BuildStatusContent - depends on email-ext, can't be migrated or exposed (BUILD_STATUS may overlap)
          • FailedTestsContent - depends on junit-plugin
          • JenkinsURLContent - depends on email-ext jenkins url (global/local to publisher)
          • ProjectURLContent - depends on ^^
          • ProjectNameContent - 2 tokens, overlaps with out of the box JOB_NAME
          • SVNRevisionContent - strange
          • TemplateContent -
          • TestCountsContent - depends on junit-plugin
          Show
          integer Kanstantsin Shautsou added a comment - - edited For 2. Need to be checked whether they tied to html generation BuildLogContent - no html, just print log lines BUILD_LOG_EXCERPT - no html, just print log lines BuildLogMultilineRegexContent – supports html optionally BuildLogRegexContent - supports html optionally BuildURLContent - generic JobDescriptionContent - generic CauseContent - generic, but token name CAUSE potentially bad WorkspaceFileContent - looks generic For 3. Not generic tokens: ChangesSinceLast* - depends on email-ext (getPreviousBuild probably can be extracted), one named CHANGES , other CHANGES* BuildStatusContent - depends on email-ext, can't be migrated or exposed ( BUILD_STATUS may overlap) FailedTestsContent - depends on junit-plugin JenkinsURLContent - depends on email-ext jenkins url (global/local to publisher) ProjectURLContent - depends on ^^ ProjectNameContent - 2 tokens, overlaps with out of the box JOB_NAME SVNRevisionContent - strange TemplateContent - TestCountsContent - depends on junit-plugin
          Hide
          Permalink
          integer Kanstantsin Shautsou added a comment -

          Seems nothing can be done with this private tokens

          Show
          integer Kanstantsin Shautsou added a comment - Seems nothing can be done with this private tokens
          Hide
          Permalink
          slide_o_mix Alex Earl added a comment -

          Migrated several tokens into token macro 1.12

          Show
          slide_o_mix Alex Earl added a comment - Migrated several tokens into token macro 1.12

            People

            Assignee:
            integer Kanstantsin Shautsou
            Reporter:
            integer Kanstantsin Shautsou
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: