--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zMNF-BJnZ%3DwSxYJiXBkExPvNUnaNU4S5Ru6p-PgJmUbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKBnHw-xjXtJHWVUFsZ%2B5vrJQJYfCmw2YNRE6Fb8h2EOotga2w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKBnHw-xjXtJHWVUFsZ%2B5vrJQJYfCmw2YNRE6Fb8h2EOotga2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMui945HN1dgibt69rDEsDHOXUoOH1gyH97p3MN3bAZEoQ4m_A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F34FB690-3946-47E6-8AC9-CB7BA5859D11%40fortysix.ch.
As you say, for compatibility reasons I don't think we can remove them.But that "brand-new way of doing frontend development" that I mentioned touches a related space. It borrows a lot of tooling from NodeJS, such as writing JavaScript in CommonJS modules, using JavaScript template libraries like handlebar, etc. My hope is that that provides a different way of building pages that require high degree of interactivity.The workflow stage view is built using this technology. I'll let Tom chime in to talk more about this.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2yZ%2Bfdy2h7UvHopdUpcUqC4zEM7jVumNoL3Ap-VwFpqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
About CI->CD.As technical person i see no benefits as it's all just a part of "automation". No matter what automate: builds, deploys, flows, etc. Automation - is what saves your time and money in any field (even non-computer).
I'm not really qualified to talk to a lot of the things you mention, but I haven't seen in the email much in the form of things like visualising CD pipelines etc. Do these types of things exist today because I think to have the goal to have our place in the CD world things like that are needed. Quite a few people at my work don't think that Jenkins is particular good for CD and point in directions such as Thoughtworks Go which, of course, is now also in the open-source arena. If they don't exist they sound like features you wouldn't want to just whip up other night to keep people happy as first impressions count.
[We collectively came quite a long way. When I started Jenkins, having a server building & testing on every commit was a cutting-edge practice. So are automatically capturing changelogs and analysing test reports. But now, those are tablestakes, and the frontier of automation has moved further. Now we are talking about building pipelines & workflows, continuously deploying to servers, leveraging containers, and/or testing pull requests before they get merged. I'm going to call this much bigger entangled automation "Continuous Delivery", to contrast this with more classical automated build & test executions (aka "Continuous Integration") that we set out to do.]I think in general, people are "Now we are *also* talking about" CD. In my mind efficient CD pipelines start with efficient CI techniques so I think its dangerous to imply that CI is no longer a thing and its all about CD. You can easily do CI without doing CD if you work in the more classical (read locked down) IT environments.
[Domain name. It's kind of a problem that we have "ci" baked into our domain name jenkins-ci.org. We have acquired http://jenkins.cd/ How about we change the domain name? I think it sends another clear signal.]Similar to my previous comment I think this is a dangerous move as it sounds like Jenkins is dropping CI in favour of CD. Also what happens when XYZ becomes the next big movement that Jenkins looks to add support for - would it change to http://jenkins.xyz? I think it would be a good idea to try and get a domain name that can stand the test of time - even if you then have the other domains forwarding through to it for catch-iness.
[All the above things call for better infra that can handle this. Right now we have our web assets are split into Drupal and Wiki, but the former can be only touched by a few people and the latter is slow and klunky. I think this is the time to switch to some static site generator, so that everyone can contribute content through Git and pull requests, just like how we collaborate on plugins.]I agree that having that mix doesn't work very well but I'm not sure it is really a requirement to dump everything that we've got today and jump to another completely different mechanism to which I'm not sure how many people would feel comfortable contributing to documentation. I (as an end user) see the main issue with Confluence as being the fact that a) perhaps the structure is not setup correctly / too much dead pages within and b) the version is SOOOO old - 3.4.7 was released 28th January *2011*! If you take a look at what Atlassian are now doing with (some) of their pages is that they are fronting the public web version with Scroll Viewport (https://marketplace.atlassian.com/plugins/com.k15t.scroll.scroll-viewport) which gives you the backend Wiki editing with the nice presentation.
[Time to bump up the system requirement to Java 8 and Servlet 3.0. Let's think about what this would enable to users. Again, we talked about this a bit in FOSDEM.]Not sure if this goal and the don't leave people sitting on 1.x goal go too well together (well the Java 8 part at least) especially given the time frames being talked about.
[Release (end Jan?)]And on the subject of timeframes I worry that its quite tight to look at something as close as January for what seems like a big piece of work. Perhaps its not but best to not understate the time requirement as otherwise Jenkins becomes like some other projects that keep saying that "the next big version" is coming out soon
As Richard, I also think that we would need some sort of a concept for a CD pipeline. I consider my self as a quite advanced jenkins user, but still I end up redesigning some sort of a CD pipeline with every new installation or even project from scratch with different plugins then I used before. CD is a great concept and sure it looks different for everyone - but people wanna have guidance and then they will be able to change it the way it works for them.In my point of view Jenkins 2.0 would need some sort of a definition for it and give answers/proposals how to do these steps together (and visualise):- build some sort of artifact (this stage might include unit tests)- promote artifacts for integration tests- do a release build- store the released artifacts (depending on the type also make it public available, e.g. for maven, npm, bower,…)- promote released artifacts to test env- trigger tests on test env- promote released artifacts to prod env(for sure the list is not complete and every step has to be plugable for different technologies, but you get the idea)I know we have all the components/plugins to solve all these issues, but its hard for a newbe (and also experienced users) to really get this right. Workflow for sure is great to go for something like this, but I think we need something on top of it (maybe its just a good documentation) to really get people into this.
w00t so if I read that correctly then we're dropping the evil job type
for Jenkins 2.0 ;-)
*unless the Maven project does a Maven 3.4.x after JDK9 is released
and before Jenkins 2.0 as then Maven 3.4.x will only be supported on
Java 9 and Java 9-1
On 25 September 2015 at 12:22, Daniel Beck <m...@beckweb.net> wrote:
>
> On 25.09.2015, at 09:04, nicolas de loof <nicolas...@gmail.com> wrote:
>
>> The fact some didn't yet upgraded to 1.8 has been discussed already, we are talking here about Jenkins runtime, not the projects it builds and deploy, that can target Java 1.1 ...
>
> 1 in 8 Jenkins jobs are based on the Maven job type, whose minimum JDK version is tied to what can run Jenkins.
>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F28E47EB-0F8C-4D9C-98E8-FB39BC13E853%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwi0pnFP9T6f%3DQLSgzefANX4i7evLjsn-cu8Dha6WtmdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
I think it's probably poor wording on my part. I didn't mean to imply that CI is no longer a thing. I think of CD as a super set of CI, in the sense that everything you do under the banner CI also contributes to CD.
2015-09-25 5:03 GMT-07:00 Stephen Connolly <stephen.al...@gmail.com>:w00t so if I read that correctly then we're dropping the evil job type
for Jenkins 2.0 ;-)Just so that the rest of the world knows you are joking. No we aren't. We need to keep it running.
*unless the Maven project does a Maven 3.4.x after JDK9 is released
and before Jenkins 2.0 as then Maven 3.4.x will only be supported on
Java 9 and Java 9-1Right, didn't Maven start splitting the JVM version in which Maven itself runs vs JVM that tests run and code gets compiled? Or is it not really a reality among users?
--To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwi0pnFP9T6f%3DQLSgzefANX4i7evLjsn-cu8Dha6WtmdA%40mail.gmail.com.
On 25 September 2015 at 12:22, Daniel Beck <m...@beckweb.net> wrote:
>
> On 25.09.2015, at 09:04, nicolas de loof <nicolas...@gmail.com> wrote:
>
>> The fact some didn't yet upgraded to 1.8 has been discussed already, we are talking here about Jenkins runtime, not the projects it builds and deploy, that can target Java 1.1 ...
>
> 1 in 8 Jenkins jobs are based on the Maven job type, whose minimum JDK version is tied to what can run Jenkins.
>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F28E47EB-0F8C-4D9C-98E8-FB39BC13E853%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--Kohsuke Kawaguchi
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4x5FmFZivYJu0%3Dro87xuGmfZgx022Ap9%3DSCHJkDUOSq2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Domain name. It's kind of a problem that we have "ci" baked into our domain name jenkins-ci.org. We have acquired http://jenkins.cd/ How about we change the domain name? I think it sends another clear signal.]Similar to my previous comment I think this is a dangerous move as it sounds like Jenkins is dropping CI in favour of CD. Also what happens when XYZ becomes the next big movement that Jenkins looks to add support for - would it change to http://jenkins.xyz? I think it would be a good idea to try and get a domain name that can stand the test of time - even if you then have the other domains forwarding through to it for catch-iness.I think I understand where you are coming from. That is, some of us see CD as just another buzzword, so getting that incorporated into the domain name is repeating the same mistake of having CI in jenkins-ci.org in the first place. I see the logic in that.In this domain name change proposal, the part that I have a stronger conviction of is that we need to drop the "-ci" part because it is creating an incorrect perception in the market that Jenkins is "just CI". In the ideal world we should get http://jenkins.org/ but unfortunately that domain is just not available.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzm33iOh3D2xU9mzbfcekVW9qHcFxvpr5%2BqKwgUd5Ab_EQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BbPaoLjXdiaMbDSwLBk%2BW1LFya_Mb55GdcQF%2B9Y%3DnxanTy%3DuA%40mail.gmail.com.
In various blogs, books and conferences like citcon I have heard the term "continuous delivery" used to mean the overarching concepts that you mention needs a new name at the end.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFzFsaoTF3BztDd_hfnAHE4HoWkueduQM_48cwvB8aOny-65Jw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKVMTi7-bdTgA3qb%2BkG_gnAz4c%2BzhX8UW2YmbS6JV1UeEmg97Q%40mail.gmail.com.
I am in year 3 of using Jenkins, and my users are complaining more about slow downs than before. As an example, the "more" link at the bottom of the build history takes too long to return for my users. I have 141 projects, 30,373 builds, and 1,073,591 junit XML test results. It took me over 20 minutes of CPU time to get these values by querying the file system.
Will Jenkins 2.0 have database backend?
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c65b5bb2-cd2f-4aae-a330-cabdd9abc8a4%40googlegroups.com.
Isn't this issue just about the thing Tom started (finished?) working on some months ago? I.e. paginating the build details.
Because indeed, on a job with lots of build, you're gonna have a bad time if you click on details. (Might be already fixed, didn't check that specific point recently)
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKVMTi76nv3f%3DWFcPodYzS5PKTsfQkhvVp_uMSY2PS2aGHiuag%40mail.gmail.com.
Isn't this issue just about the thing Tom started (finished?) working on some months ago? I.e. paginating the build details.
Because indeed, on a job with lots of build, you're gonna have a bad time if you click on details. (Might be already fixed, didn't check that specific point recently)
Jenkins is over 10 years old, and it came quite a long way. I still remember the first few plugins that I wrote by myself, and now we have close to 1100 plugins. What's started as a hobby project that had run under my desk today boasts more than 100K installations driving half a million-ish build machines.
We collectively came quite a long way. When I started Jenkins, having a server building & testing on every commit was a cutting-edge practice. So are automatically capturing changelogs and analysing test reports. But now, those are tablestakes, and the frontier of automation has moved further. Now we are talking about building pipelines & workflows, continuously deploying to servers, leveraging containers, and/or testing pull requests before they get merged. I'm going to call this much bigger entangled automation "Continuous Delivery", to contrast this with more classical automated build & test executions (aka "Continuous Integration") that we set out to do.
The other thing I'd like to point out is that the adoption of Jenkins continues to grow at the incredible pace of 30% year over year. That is, a lot of people are starting new with Jenkins, and they are looking for us to help them get Continuous Delivery done. Therefore, this is a good time to step back and think about whether we are addressing those current user demands.For example, despite this advance during the last 10 years and 1000+ plugins we've created, messaging in our website hasn't changed much since the first version I wrote on java.net. It spends more space talking about JNLP and zero mention of Git, pipeline, or Docker.The fresh installation of Jenkins is not much better. The CVS support is available out of the box, but Git isn't. All the cool stuff that the community has done and its collective best practices still need be learned by each and every new user. It's bit like we are making everyone assemble LEGO blocks. That's not doing enough justice to the 30K+ users that will be joining us in this year.So I propose we do Jenkins 2.0 to fix this.There are three important goals that I see in Jenkins 2.0.
- We need to claim our rightful place in Continuous Delivery. We have lots of pieces that address these modern needs, but we are not communicating this very well.
- We need to revisit out of the box experience, so that Jenkins itself speaks that story and makes it clear what we are aiming for. Our software needs to speak for itself and tell people where we are going, so that the community can better focus efforts on the important parts.
- And we need to do this while keeping what makes Jenkins great in the first place, which are the ecosystem, the community, and the extensibility that recognizes that one size does not fit all and let people do what they want to do.
Incrementing the major version sends a clear message to people that we are moving forward. That's why I think 2.0 is appropriate for this effort.Now, 2.0 can mean a lot of different things to a lot of people, so let me outline what I think we should do and we shouldn't do.It's very important for me to make sure that my fellow Jenkins developers understand the motivation and the goal of this proposal, because that drives much of what we should and shouldn't do. So instead of deep-diving into technical parts, please take time to try to understand why I am proposing this.We need to contain the scope. 2.0 has to have enough in it to justify the major version number increase, but it creates a period of pause and uncertainty, so it cannot keep dragging on for too long. 2.0 cannot be everything everyone ever wanted.We cannot do massively disruptive 2.0, because it ends up splitting the community. If users perceive that the upgrade to 2.0 is risky, enough of them will stay behind with 1.x, plugin authors would want to continue supporting them, which makes 1.x more liveable, which makes the transition slower. I do not want to end up in Python2/3 situation, and nobody wins.That means we cannot be really breaking plugins. We cannot do s/hudson/jenkins/g in the package names because doing that will break all the plugins. 2.0 does come with the expectation that it is more disruptive than usual 1.630 to 1.631 upgrade, so we have some "disruption budget", but we have to use it really wisely.Simiarly, for me it is an absolute requirement that we keep people's $JENKINS_HOME functioning. A lot of sweat, tear, and blood went into those right set of plugins and elaborate job configurations. When users upgrade to 2.0, they need to continue to work, or else Jenkins 2.0 will be Jenkins in just the name only.Therefore, we cannot make massive internal changes. In many ways, it has to be evolutionary instead of revolutionary, when it comes to the code. This is not a "let's redo everything from scratch" kind of 2.0. In any case, I think it's a pitfall to focus too much on internals. We all have a long list of things we want to fix and the technical debt that we want to pay down. My cautionary tale here is that of Maven 2 to Maven 3 upgrade. The developers of the project spent a lot of efforts redoing all the plumbings. Plexus gave way to Guice, and the dependency resolution engine got completely rewritten. Then to keep plugins working, more efforts were spent on building the backward compatibility layer. After something like 18 months, Maven 3 came out, which did more or less the same thing as far as users are concerned. I'm sure I'm over-simplifying this, but you get the point.So given all that constraints, I think 2.0 should have the following 3 major pillars:
- Messaging changes, to make sure people coming into the Continuous Delivery space will get that Jenkins does what they want.
- Software that backs up our messages. Out of the box experience that caters to Continuous Delivery needs.
- Targeted internal plumbing changes that enable those goals
I have some concrete ideas in each of these pillars, and I'll describe them below. But I also need help from everyone to come up with, discuss, and decide what other things will advance those pillars.Messaging:
- Domain name. It's kind of a problem that we have "ci" baked into our domain name jenkins-ci.org. We have acquired http://jenkins.cd/ How about we change the domain name? I think it sends another clear signal.
- We need more up-to-date feature list page (like http://arquillian.org/features/) that talks about things that matter to the modern users.
- We need authoritative and curated getting started guide that expands on the things listed in the features page and help people understand those features, so that we have clearly marked trails.
- This is probably out of scope for the initial 2.0 launch, but in the future we want to redo the plugin listing page as well. This is a persistent feedback that we hear from users.
- All the above things call for better infra that can handle this. Right now we have our web assets are split into Drupal and Wiki, but the former can be only touched by a few people and the latter is slow and klunky. I think this is the time to switch to some static site generator, so that everyone can contribute content through Git and pull requests, just like how we collaborate on plugins.
Out of the Box Experience:
- This work is already in progress, but we really need some initial setup wizard. We can use it to install plugins so that new instances come up more useful from get-go --- things like git, workflow, pipeline as code, folders, and so on. These plugins together tell the story of how we want users to use Jenkins.
- Another work that's already under way is the UX improvement, specifically the config form re-layout. This is the kind of change that helps people (literally) see that 2.0 is different. UX in general is clearly one of the places we should spend our precious disruption budget for.
- To reinforce the message that workflow is the future, CloudBees is going to open-source our workflow stage view plugin that was previously a part of CloudBees Jenkins Enterprise.
Internals:
- Let's define a policy to remove APIs after they are deprecated. We have talked about this in FOSDEM, and this could be as easy as "N releases after deprecation". Feedbacks from users at the San Jose JAM was that things like this is OK, but we need to help people identify plugins that will be impacted to give them earlier warnings.
- As a part of the UX rebump effort, Tom et al has been working on a brand-new way of doing frontend in Jenkins plugins. His JUC talk has some materials. Given that user experience is a major theme in 2.0, I think this internal plumbing change makes sense.
- Let's use the opportunity to update some of the libraries. I'm thinking about things like Groovy, which according to the testing done during Copenhagen Hackathon, should be compatible. This shouldn't include updates that are known to be compatibility breaking, such as Acegi Security to Spring Security (which involves package name changes.)
- Time to bump up the system requirement to Java 8 and Servlet 3.0. Let's think about what this would enable to users. Again, we talked about this a bit in FOSDEM.
Finally, timeline-wise, my aspirational timeline is as follows, though obviously this is largely dependent on feedback to the proposal:
- Announce the proposal publicly and have discussions to nail the details (Sep-Oct)
- Execution (Oct-Dec)
- Periodic alpha/beta releases to solicit feedbacks from users
- PR activities
- This phase concludes with the release candidate
- Plugin sweep to ensure key plugins are "2.0 ready". This is the opportunity to find issues (Jan 2016)
- Release (end Jan?)
- Drop 1.x development as soon as possible to focus on 2.x.
There are a lot of things I haven't captured, but this email is aleady getting too long. Looking forward to having more conversations about this with everyone.--Kohsuke Kawaguchi
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zMNF-BJnZ%3DwSxYJiXBkExPvNUnaNU4S5Ru6p-PgJmUbw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83Rx3Nt2ecARsqez1D%2BQ_wQbTfneSHq5cm9UQhfQ9Am3kA%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83Rx3Nt2ecARsqez1D%2BQ_wQbTfneSHq5cm9UQhfQ9Am3kA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKVMTi6Ehmqd-Vc4JFJqi9idiutzNK_n9Xc5a6u2-zc5QhMdgw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzmeJNsHi9XCPUfDirmcc7fKREG5Ljw_y1UbOCMf6-Y%2Beg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS74qrB_DK81JthYdhXsOoc%3Dq4se7CcuJk6yB2%2Bf5STOyw%40mail.gmail.com.
if you consider 10 years of jenkins development, I don't think the issue is for dependencies to become old "too quickly", but the fact we hardly can change them without potential risk to break some plugin.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzmeJNsHi9XCPUfDirmcc7fKREG5Ljw_y1UbOCMf6-Y%2Beg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/153b5592-f7ea-4461-9a45-0a630bf072c0%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B4338EB6-0D6F-4701-AD59-FC5C92B4DE54%40beckweb.net.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D7546C53-275C-4445-B967-94C44B421915%40beckweb.net.
[Domain name. It's kind of a problem that we have "ci" baked into our domain name jenkins-ci.org. We have acquired http://jenkins.cd/ How about we change the domain name? I think it sends another clear signal.]Similar to my previous comment I think this is a dangerous move as it sounds like Jenkins is dropping CI in favour of CD. Also what happens when XYZ becomes the next big movement that Jenkins looks to add support for - would it change to http://jenkins.xyz? I think it would be a good idea to try and get a domain name that can stand the test of time - even if you then have the other domains forwarding through to it for catch-iness.I think I understand where you are coming from. That is, some of us see CD as just another buzzword, so getting that incorporated into the domain name is repeating the same mistake of having CI in jenkins-ci.org in the first place. I see the logic in that.In this domain name change proposal, the part that I have a stronger conviction of is that we need to drop the "-ci" part because it is creating an incorrect perception in the market that Jenkins is "just CI". In the ideal world we should get http://jenkins.org/ but unfortunately that domain is just not available.As jenkins.org do redirect to stevejenkins.com, dit you tried to contact registrant and propose to acquire the domain name ?
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzm33iOh3D2xU9mzbfcekVW9qHcFxvpr5%2BqKwgUd5Ab_EQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPoyBqRbzzq_%2BJiGX8qMb5QV27xCwsRxcgtELfA_ytw933_oqw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0g%3D%2Bq4cu4h9TOyqX0YCApgOPjJxT8SojcppJZPbm%2BfTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
>>> I have 141 projects,
>>> 30,373 builds, and 1,073,591 junit XML test results. It took me over 20
>>> minutes of CPU time to get these values by querying the file system.
>>
>> Yes, build storage is a well-known architectural problem. PR 1641 will
>> not help you here.
Just to add another data point that might be interesting. I am running a large Jenkins instance (version 1.565.1) with 123 different plugins installed. It contains, 1,021 projects (711 are matrix jobs) with 26,040 builds (454,575 matrix sub-job builds) and 14,988,971 test results. The build results take up about 1.8TB disk space.
The Jenkins master runs on a 24 core machine, with 64GB RAM, 2.5TB RAID 10 storage (~ 200 MB/sec peak I/O). The build slaves are run on secondary machines.
The startup time for this Jenkins master is about 40-60min. Taking the raw I/O performance on this system into account, the theoretical absolute lower limit should be just under 6min.
Reading all my test XML reports directly from the filesystem took about 31min.
For comparison, accessing these same results through the REST API takes about 45min.
>>> Will Jenkins 2.0 have database backend?
>>
>> No, the changes required are too big. There is no way to do it that
>> quickly. I think we *should* do these changes sooner or later. For me
>> this seems both more important and more disruptive than the code
>> changes currently being discussed for 2.0.
>
> Yeah, I tend to agree. It is an important issue, but as Jesse says,
> I'm afraid it's too disruptive than all the boundaries that we operate in.
>
> We should still take it on, but it shouldn't be tied to Jenkins 2.0.
Not knowing much about the internals of Jenkins, my suspicion is that most plugins deal with I/O by themselves. If this is indeed the case, then in my experience it is usually bad for performance to let everyone do their own thing for I/O. I would then suggest as a first step to enforce plugins to use a unified I/O interface.
Later it would be much easier to redirect that to a DB backend.
Perhaps this idea has already been raised by the core developers. :-)
Kind regards.
Artur
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3d9TFBDUeBQ%3DmewV5y02Ap0cxywnCvkUjcoq3z5b%3D1eg%40mail.gmail.com.
The new Plugin Install Wizard is an example of the sort of UX improvement we could target for a 2.0 release. See this short video of the current progress there: https://youtu.be/9pq5tHm4nWsIt is using the modularised JavaScript approaches we talked about earlier in this thread
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e23aac54-ae6e-48b1-9cfd-434b6d30fa1e%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20150930024339.GH2353%40blackberry.coupleofllamas.com.
From a UI perspective, another thing I would like to see baked into a 2.0 is push notifications to the browser so we can get rid of the polling that happens in many places (e.g. the build history). It would need to be bi-directional (websockets). Something based on SSE/Long-poll would work.
Great post Kohsuke. Thank you for creating Jenkins.>Time to bump up the system requirement to Java 8 and Servlet 3.0. Let's think about what this would enable to users.I've been using Java 8 for serverside rendering of react fontend for dotci using Nashorn. It has been working beautifully.
On Wed, Sep 30, 2015 at 9:59 AM Surya Gaddipati <suryap...@gmail.com> wrote:Great post Kohsuke. Thank you for creating Jenkins.>Time to bump up the system requirement to Java 8 and Servlet 3.0. Let's think about what this would enable to users.I've been using Java 8 for serverside rendering of react fontend for dotci using Nashorn. It has been working beautifully.Oh that is quite interesting. By react you mean react from facebook?
Servlet 3.0 would be great for doing push to browser updates instead of constant polling that I have to do now. This has been a terrible for scaling our jenkins setup.
OT: if you can buy some ssd disks and raid them so you can get space and redundancy you will probalg see an order of magnitude difference. I had start up times of 3 hours which fell to 3 minutes... As for tests have you tuned the jvm memory settings? If not then the results get garbage collected whilst loading other results that are needed which keads to the results being loaded again which leads to.... And eventually enough loads and gcs pass that it works again.
Apart from artifact/log archival/retreival most of the io in jenkins will be loading small files and random Iops is king not sequential bandwidth. YMMV standard disclaimers apply
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7f434dd9-a7c6-4477-ac46-43bf34dbb8b4%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BbPaoLXGC85XTg8yXdfQWxQ9C_2LznskYJB_om0vBKot6FNsg%40mail.gmail.com.
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOYtrnhrkZORCTzGxgRrMhydS%3DzEKRAS8FffPaK_24Ln2A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BbPaoJ9Hisv0t62OJ9ka9bXGAbVrQK9zBbyFoc79sQew%2BEwsg%40mail.gmail.com.
Some thoughts...jenkins.cd is a bad idea. It has a weird feel to it - I've never seen another .cd domain. It's more narrow and marketing-specific than jenkins-ci.org, as has been said. Honestly, it feels more like a startup domain than an OSS project domain. If we can get jenkins.org or another of the more common TLDs, sure, that's an improvement, but jenkins.cd just doesn't feel right.
I'm not comfortable with the timeframe - this is our best opportunity to make major architectural changes to core for a long time, and we should really take advantage of that. Let's have real discussions about breaking compatibility in some places, re-doing the backend storage (I strongly feel we should move core's storage (and quasi-core plugins like junit-plugin, Maven/matrix job types, etc) to an abstraction layer - so that it becomes possible to move builds/tests/etc to be stored in something other than XML), etc.
Given that I think 2.0 should be more radical a change than proposed, I also think we should keep the 1.x LTS line going for like a year - just bug fixes, of course, but we'd really need to have a path for people to take time to move off of removed functionality or plugins that won't work any more in 2.0, etc, and keeping up the LTS track is a necessary part of that.
A.--On Thu, Oct 1, 2015 at 12:31 AM, James Nord <james...@gmail.com> wrote:OT: if you can buy some ssd disks and raid them so you can get space and redundancy you will probalg see an order of magnitude difference. I had start up times of 3 hours which fell to 3 minutes... As for tests have you tuned the jvm memory settings? If not then the results get garbage collected whilst loading other results that are needed which keads to the results being loaded again which leads to.... And eventually enough loads and gcs pass that it works again.
Apart from artifact/log archival/retreival most of the io in jenkins will be loading small files and random Iops is king not sequential bandwidth. YMMV standard disclaimers apply
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7f434dd9-a7c6-4477-ac46-43bf34dbb8b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOYtrnhrkZORCTzGxgRrMhydS%3DzEKRAS8FffPaK_24Ln2A%40mail.gmail.com.
Go for it! Those 4 digit minor numbers are getting a bit long :-)I'd just go for the UX/UI theme as 2.0. Not that all other things are desirable too, but just the visual part could be a big boon and some disruption for the plugin community as well. That said, is UI going to be important going forward with DSL and Workflow?
I also think documentation improvements could be really helpful.* For example I could not find a definition of the general Queue mechanism and discipline, only references in plugins that change it. But nothing authoritative.* Similar, the documentation of extension points and API's is gravely lacking (what is getBuildVariables() supposed to do? Can it call getEnvironment()? Not if it wants to interoperate with a later build of the SVN plugin, which calls getBuildVariables() in the getEnvironment - poof stack overflow - who's fault is it? Oh, why does getBuildVariables() not have any access to a logger?)
I personally love Wikis (at least those that accept Wiki syntax, which Atlassian messes up with its newer versions and standard Wysiwyg editors that break everything).
I don't want to get into the CI vs CD definition argument, but I think CD is less narrow than CI.Initially I wasn't very keen on the new domain name myself, but over the time it growed on me and I started seeing the point of it. Name is important, and domain name is one of the first things that people see.
I assume you mean storing XML in something other than a file system.
I just don't see how this can work out. A fundamentally incompatible 2.0 that takes a lot longer to do, which breaks massive number of plugins. And then we let those people stay on Jenkins 1.x longer. It's going to significantly delay the launch of 2.0, then delays the migration further out.
I'm not saying storage pluggability is a bad idea, it's the opposite. It's just that with all things considered, I don't think it's the best move to spend our precious resources on it at the moment. As I wrote, this is trying to cater to people who are newly coming to Jenkins, which is big in numbers. And for those who are running huge deployments, what eBay/Paypal/CloudBees/etc are doing --- lots of small masters in an elastic environment instead of one giant monolithic master --- makes a lot of sense, and addresses # of other related problems that those guys face.
But you aren't the first one to point out about the storage pluggability. So maybe there's some version of it that can be done reasonably that's also compatible over time. That is, we could still require one directory per build, but at least store build records and job configurations elsewhere to help startup time and build history traversal. Kind of like what DotCi does.
On Fri, Oct 2, 2015 at 10:21 PM, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:I don't want to get into the CI vs CD definition argument, but I think CD is less narrow than CI.Initially I wasn't very keen on the new domain name myself, but over the time it growed on me and I started seeing the point of it. Name is important, and domain name is one of the first things that people see.I'm still not persuaded. =)
I assume you mean storing XML in something other than a file system.Or theoretically serializing to something other than XML - that'd be tougher, obviously, but not *much* harder.
I just don't see how this can work out. A fundamentally incompatible 2.0 that takes a lot longer to do, which breaks massive number of plugins. And then we let those people stay on Jenkins 1.x longer. It's going to significantly delay the launch of 2.0, then delays the migration further out.I'm not advocating incompatibility for the sake of incompatibility - just saying that this is our opportunity to make significant architectural changes, so we should at least consider them.I'm not saying storage pluggability is a bad idea, it's the opposite. It's just that with all things considered, I don't think it's the best move to spend our precious resources on it at the moment. As I wrote, this is trying to cater to people who are newly coming to Jenkins, which is big in numbers. And for those who are running huge deployments, what eBay/Paypal/CloudBees/etc are doing --- lots of small masters in an elastic environment instead of one giant monolithic master --- makes a lot of sense, and addresses # of other related problems that those guys face.Yeah. A bunch of things are just not really viable with the current storage - HA most notably, etc.But you aren't the first one to point out about the storage pluggability. So maybe there's some version of it that can be done reasonably that's also compatible over time. That is, we could still require one directory per build, but at least store build records and job configurations elsewhere to help startup time and build history traversal. Kind of like what DotCi does.Yeah, that's pretty much exactly what I'm hoping for.
Isn't this issue just about the thing Tom started (finished?) working on some months ago? I.e. paginating the build details.
Because indeed, on a job with lots of build, you're gonna have a bad time if you click on details. (Might be already fixed, didn't check that specific point recently)
Personally still trying to decide if it's visionnary or weird ;-).But indeed, jenkins.cd is also growing on me. Maybe others system will just follow The Jenkins Way like they all struggle to do currently ;-).
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/05D2F6BB-60E8-4E2F-A12D-D2352FA8804F%40beckweb.net.
>Oh that is quite interesting. By react you mean react from facebook?
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83QFhjXG%3DxVjBjthuYTtt8eL6HR8KpHgA1oPO3XMbRkHFw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4855a7f7-fd5f-4e81-9703-72b9818a72cd%40googlegroups.com.
>Surya, in your case has being DB backed helped load times? (If you can say)
>Surya, in your case has being DB backed helped load times? (If you can say)Yes, definitely. That was the original impetus behind moving stuff into the database. We went from > 45 mins load time to < 1 min.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f71e5a1d-bb4d-42be-a3d1-21f32f76792e%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKVMTi63wrax1ewP1v9DC3N7sGifg0RG%2BuetE5x3dSTcw5t7kg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9d9e1968-b7c7-4296-899c-f2b05f10ac6a%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zpgWrGyuE0KkfKejMxSVuXNgabdL6K5XTnZRo5k1uAhg%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/vbXK7JJekFw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOZaTbv6LQqPvDV56tWSxbX1Au%3DBC2uBcAwc0cxqL17OpA%40mail.gmail.com.