My team and I designed Blue Ocean. We are really excited to get your feedback and suggestions. Ask me anything :)
Please instead establish any kind of directory that is expected where all that project and tooling related meta files are kept, I would like to suggest a top level folder called "config" - but I really do not care, how this is called, as long as that top level config file annoyance will disappear forever.
I believe it might be acceptable to expect exactly one optional top level config file that might be called "configrc" that would contain only the path of that actual config path if this is not in a default place.
Thank you very much for your attention!
If you needed any additional configuration for Jenkins specific instructions then that would be in a folder called ".jenkins"
Sadly, people did not embrace that project type... perhaps because it was given the nerdy name "literate" by a colleague of mine (who's name rhymes with Nichale Meale)
My biggest issue with Jenkins so far has been configuring complex jobs. The single configuration page just gets unwiedly fast, and important settings are often hidden by default.
Is there any work being done to make this easier as well?
There's a trend to move job configuration to a Jenkinsfile that's stored in a Git repository using Jenkins Pipeline. What used to be several jobs is now one Pipeline job config defined using this DSL https://jenkins.io/solutions/pipeline/
Today the pipeline visualization only works with this way of making jobs.
Now we realize this isn't for everyone and we are thinking about how to let users create Jenkins Pipelines through the UI without having to know the DSL (just like freestyle). We are also looking at making Pipeline easier for beginners too.
While Pipeline looks awesome for sophisticated entities that have complex workflow it seems overly powerful for most I think that just have a lot of projects and configuration drift.
Pipeline unlike Travis Yaml is also not a declarative language. One of the advantages of using a declarative markup language that respects comments and spaces (cough XML) would be for the Web UI editor to intelligently edit the configuration files while respecting order, formatting and comments (right now I believe Jenkins XStreams so its just naive serialization).
However, it turns out that tree-structured documents struggle to describe build graphs.
Something like "node { sh './build.sh' }" will work fine.
But you can also build your own simplified syntax on top of Pipeline, e.g. I believe there is a prototype out there that will run Travis .yml scripts in a Pipeline job, and there are already plugins that simplify the Pipeline syntax, e.g. https://wiki.jenkins-ci.org/display/JENKINS/Simple+Build+For...
I haven't tested it with the newer Jenkins 2.x versions, but you may want to try it to see if it helps.
https://www.opsfordevelopers.com/2015/03/jenkins-show-advanc...
I also added the main contributors of the repository to the Open Source Design collective at https://github.com/opensourcedesign, more info at http://opensourcedesign.net – welcome! :)
try that to build missing artifacts. It worked for me.