halkeye on java11-support
update jenkins base version and… minor fixes to support latest m… Few more powermock ignore fixes… and 19 more (compare)
halkeye on notify-github
Cleanup statuses (compare)
halkeye on notify-github
Move the start/stop of bitbucke… Notify github that we are build… Add a bunch more descriptions f… (compare)
halkeye on update-acceptance-tests-deps
Github warned about a bunch of … (compare)
halkeye on remove-all-nightwatch-tests
halkeye on master
Remove all nightwatch tests (#1… (compare)
Hi All. I'm after some advice about how best to replace a blueocean plugin, blueocean-pipeline-api-impl in this case, with a private version. For background, my working environment blocks direct access to GitHub and provides a local Artifactory instance from which I fetch mirrored plugins and to which I deploy my own version. The path I've been down is to mimic the the blueocean-plugin (maven parent) and declare my own plugin (eg blueocean-pipeline-api-impl :1.24.5-myplugin) as a dependency. Things work with hpi:run and I can run blueocean successfully and get the functional changes I want from my own blueocean-pipeline-api-impl . My replacement parent uses my own namespace eg com.mycompany and I ended up having to use io.jenkins in the private Artifactory to succeed with the child plugin. All good until I try to deploy to a staging environment where, when I bake my Dockerised Jenkins image (derived from jenkinsci/docker) using the jenkins-plugin-cli to add my child and parent plugins, the cli instead resolves the original plugin. I've gone through each plugin that declares a dependency on blueocean-pipeline-api-impl and added an exception in the parent plugin to try and workaround this but to no avail.
What I'm after is guidance on the best approach to take for this case of a bespoke version of a child plugin. It may be that my only problem is now with jenkins-plugin-cli but it's also likely that someone can point me to a better pattern for how to go about the whole thing.
2021-06-14 09:43:20.175+0000 [id=11] WARNING o.e.jetty.server.HttpChannel#handleException: /reload-configuration-as-code
@DJViking I think most of the original Cloudbees crew who worked on BlueOcean have left Cloudbees. The way that BlueOcean was implemented was a "big bang" that adopted technologies not used before in the core Jenkins stack.
Unfortunately, BlueOcean is a bit complicated (combinations of Java + NodeJS), so it is tough for the community to step in and maintain the code, and keep it going.
It's too bad, because the visualization of pipelines is quite nice in BlueOcean, and nothing else I have seen in the Jenkins ecosystem comes close.
It looks like the latest commits to the jenkinsci/blueocean-plugin repository are trivial commits to bump up dependencies.
shsteps to have a
label:field, but Blue Ocean is only using some of them properly in the UI