[JENKINS-57877] - A Test Step to confirm the Builds have been Promoted.

[dernDren161]

As part of #128 this PR is for spot check/test automation for users to know that the upstream build is promotable/promoted. In the later Phases of this Project this step would probably be replaced by a Job Triggering action to label the Promotion. The expected function name for this step is : addTestBadge

Note: This step Would be seen effective after the introduction of other Promotion Steps so as to test their effectivity.
Link to relevant PR: this
Plan for the Step.
pipeline{
agent any
stages{
stage('Self Promotion'){
steps{
selfPromote(String job,int buildNumber,boolean b){
addTestBadge(String job,int buildNumber)}
}
}
}

Further Information: The step is expected to give a LOGGER message on successful promotion of the previous Jobs.
Also Please Help rectify the code on any technical glitches.

Test Results:

• The module was compiled successfully and the plugin was hosted in the local server as well.
  Problem:
• The pipeline option in the "New Item" list was not found to test the DSL step(Need suggestions on this).
  Report:
• Though the module compiled correctly but however is not tested fully due to the above point(Need Suggestions)
  Conclusion:
• Need further Revisions on the Code itself and about testing.

See JENKINS-57877.

Your checklist for this pull request

• Pull request title represents the changelog entry which will be used in Release Notes. JIRA issue is a part of the title (see existing PRs as examples)
• Please describe what you did. Short summary for reviewers. If the change involves WebUI, add screenshots
• Link to relevant Jenkins JIRA issues or pull requests
• Test automation, if relevant. We expect autotests for all new features or complex bugfixes
• Documentation if relevant (new features). We want to use Documentation-as-Code, just put docs to README or to new Doc files
• Javadoc for new APIs. Any public/protected method is considered as API unless annotated by Restricted (docs)

CC

@oleg-nenashev @jonbrohauge @bicschneider @MadsNielsen

[oleg-nenashev]

If this is a test step, it should be in the 'src/test/java' so that it appears in tests only.
If this is intended to be a production code, it should be written and named accordingly

[dernDren161]

If this is a test step, it should be in the 'src/test/java' so that it appears in tests only.
If this is intended to be a production code, it should be written and named accordingly

@oleg-nenashev Hi sorry for this implementation. I assume that this looks more like a production code. So this step should be placed before any other promotions i guess?! I'll reuse the PR with minor changes done to it. Will that work?

[oleg-nenashev]

@dernDren161 it will not work as is. You are still trying to add the test code to the production codebase which will go to users. If you want to have addTestBadge() added to the production code, it should be renamed accordingly. Also, Jelly files and documentation would need to be added so that the step becomes editable in the Snippet generator.

[dernDren161]

@dernDren161 it will not work as is. You are still trying to add the test code to the production codebase which will go to users. If you want to have addTestBadge() added to the production code, it should be renamed accordingly. Also, Jelly files and documentation would need to be added so that the step becomes editable in the Snippet generator.

@oleg-nenashev Thanks for the response. What you suggested in the KT session PR was to have a test step before the promotion modules even begin to run? So i understand this PR method won't work and needs changes. So my requests to you:

1. Please share some code samples that address similar kind of testing since it would be way easier to find things out quickly, i could not spot them though i looked at many sources. It would save a lot of time as this is just a test step the main thing is yet to come. And also it took a lot of time for me to even frame this PR so plese share in some documentations for this.
2. Also i wanted to send a separate PR for the addPromotionBadge because by the time the test step PR gets accepted i could parallely work on the main refactorings for which i need the rest refactorings done from you in the KT session merged. I could then push my Promotion Conditions then. While i accept the addTestBadge should be the very first step into doing things.

Thank You!

[oleg-nenashev]

Please share some code samples that address similar kind of testing

1. Move the code to the src/test location
2. Create tests which invoke the step. There are plenty of examples , e.g. in [JENKINS-40765] add pipeline support release-plugin#22
3. Change extension to @TestExtension. https://github.com/jenkinsci/jenkins-test-harness/blob/master/src/main/java/org/jvnet/hudson/test/TestExtension.java

[dernDren161]

Please share some code samples that address similar kind of testing

1. Move the code to the src/test location
2. Create tests which invoke the step. There are plenty of examples , e.g. in jenkinsci/release-plugin#22
3. Change extension to @TestExtension. https://github.com/jenkinsci/jenkins-test-harness/blob/master/src/main/java/org/jvnet/hudson/test/TestExtension.java

@oleg-nenashev ok Thank You so Much now it makes sense to me, all this while i thought testing meant testing Jobs from the DSL but no. Also just to reconfirm i guess sth similar to only : (this) is required for now? Like make a module which you think is pipeline compatible, create a Test to check the modules.
So here,
Create a Step(already created above) - then test it with a Test code(to be made) - move both of them to src/test - Put @TestExtension to both of them.
Please comment if anything above is wrong. Thank You!