@pushker001 please review the video included at
That video series includes several different cases where pull requests are submitted.
Youâre not following the instructions in the document. Please follow the instructions in the document. The instructions say:
- Checkout a branch to perform the work
git checkout -b add-spotbugs-checks master
- Add or modify the properties in the pom.xml file
<properties>
<spotbugs.effort>Max</spotbugs.effort>
<spotbugs.threshold>Low</spotbugs.threshold>
</properties>
- Create a pull request
git add pom.xml src/spotbugs
git commit -m "Increase spotbugs effort and threshold"
git push origin --set-upstream add-spotbugs-checks
Notice that the output of the command includes the URL, which can be used to open a pull request. Copy that URL in your web browser and submit a pull request.
Problems I see
Your screenshot shows that youâre using a different branch name than is provided in the instructions. Your screenshot hints that your incorrectly named branch also contains no commits beyond the commits that are on the master branch of the upstream repository. That likely means you didnât push the commit from your local computer to GitHub. You may also have failed to commit it locally on your computer.
actually, i am doing all this through the video you have provided not doing from the document
please tell me what to do after this I was watching a video that @MarkEWaite share.
my interface is different that shown in video.
@pushker001 you need to follow the instructions on the page of the âImprove a pluginâ tutorial. Those instructions suggest things that you could consider including in the contributing guide. If you choose to add an item, be sure that you confirm it works (for example, coverage reporting).
Thanks for including that screenshot. That page needs to be updated to include Java 17 and to remind maintainers that Java 11 is the most popular Java version for Jenkins users currently.
To run a plugin locally, the command is:
mvn hpi:run
That starts a Jenkins controller with the minimum Jenkins version supported by the plugin and loads the plugin and its dependencies into that controller. Jenkins will be running on port 8080 and can be reached with the URL http://localhost:8080/jenkins/
If a plugin maintainer wants to use a different Jenkins version, they run the command:
mvn -Djenkins.version=2.375.1 hpi:run
If a plugin maintainer wants to use a different HTTP port, (as in http://localhost:9090/jenkins) they run the command:
mvn -Dport=9090 hpi:run
If a plugin maintainer wants to allow other computers to access that Jenkins controller while it is running, they run the command:
mvn -Dhost=0.0.0.0 hpi:run
See the maven hpi plugin documentation site for more details.
Built-on-column-plugin
This plugin Adds a column on the jenkins dashboard that shows the actual node the last build was run on.
Why should you contribute
You can contribute in many ways, and whatever you choose weâre grateful! Source code contribution is the obvious one but we also need your feedback and if you donât really want to participate in the implementation directly you may still have great ideas about features we need (or should get rid of).
We have our vision for the plugin and we have an experience with maintaining Jenkins instances, but the plugin is not supposed to solve only our problems. Surely we havenât experienced all of them⌠Thatâs why we want to hear from you.
Please use GitHub issues if you need to report a bug or request changes/improvements. Whenever you report a problem please provide information about:
- Plugin version (Configuration as Code plugin as well any other plugin you suspect your problem to be related to)
- Jenkins version
- Operating system
- Description!
Run Locally
Prerequisites: Java, Maven
- Ensure Java 8 or 11 is available.
$ java -version
- Ensure Maven is included in the PATH environment variable.
export PATH=$PATH:/path/to/apache-maven-3.8.6/bin
- To run a plugin locally, the command is:
mvn hpi:run
- That starts a Jenkins controller with the minimum Jenkins version supported by the plugin and loads the plugin and its dependencies into that controller. Jenkins will be running on port 8080 and can be reached with the URL http://localhost:8080/jenkins/If a plugin maintainer wants to use a different Jenkins version, they run the command:
mvn -Djenkins.version=2.375.1 hpi:run
- If a plugin maintainer wants to use a different HTTP port, (as in http://localhost:9090/jenkins) they run the command:
mvn -Dport=9090 hpi:run
- If a plugin maintainer wants to allow other computers to access that Jenkins controller while it is running, they run the command:
mvn -Dhost=0.0.0.0 hpi:run
is this ok?
That looks good to me.
Looks reasonable, though it is much more effective for me (and others) to review changes in GitHub pull requests rather than reviewing them in screenshots. No problem if there are flaws or imperfections in the pull request. We learn together and we learn by pull requests.
3 Likes
I think this one needs some TLC: GitHub - jenkinsci/promoted-builds-plugin: Jenkins Promoted Builds Plugin
1 Like
I think that promoted builds plugin may be a little too high visibility and high complication than you are ready to attempt @pushker001 . If youâre willing to try a few other plugins, they would give you a better experience with lower risk and as much learning as youâll get from promoted builds. Try the following plugins instead:
- Discard old builds plugin - GitHub - jenkinsci/discard-old-build-plugin: More build discard settings for freestyle jobs
- Skip certificate check plugin - GitHub - jenkinsci/skip-certificate-check-plugin: Bypass HTTPS certificate checks
I just completed a first step on those two plugins to perform minimal modernization so that new versions could be released. They both would benefit from:
- More spotbugs checks
- Add a contributing guide
They would also benefit from additional automated tests if you would like to learn more about writing automated tests with JUnit.
2 Likes
yes sure I would love to learn about writing automated test