Re: Adventurous users wanted! Literate multi-branch project type
Am I right that the plugins are no longer present in the experimental update centre? If so, then does that mean I need to build them from source? ATB - Dave English, Wiredthing -- View this message in context: http://jenkins-ci.361315.n4.nabble.com/Adventurous-users-wanted-Literate-multi-branch-project-type-tp4677934p4687545.html Sent from the Jenkins dev mailing list archive at Nabble.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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
I see them in http://updates.jenkins-ci.org/experimental/ so not sure what you are getting at... On 14 January 2014 16:36, sandersw d...@wiredthing.com wrote: Am I right that the plugins are no longer present in the experimental update centre? If so, then does that mean I need to build them from source? ATB - Dave English, Wiredthing -- View this message in context: http://jenkins-ci.361315.n4.nabble.com/Adventurous-users-wanted-Literate-multi-branch-project-type-tp4677934p4687545.html Sent from the Jenkins dev mailing list archive at Nabble.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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
On Thursday, 3 October 2013 20:37:27 UTC+1, Stephen Connolly wrote: On Thursday, 3 October 2013, teilo wrote: Hi Stephen, Is the literate plugin going to be the only route into the multi-branch job? I am sure somebody may use the branch api to implement other types... I have a freestyle multi branch but there is just too many build differences for it to be useful and a ton of UI glitches because plugins assume they are owned by ? extends Job Reason being for enterprisy software we need to enforce things in a build/release so I can't let my users run abitrary maven invocations that change the build (and make it unreproduceable). e.g. they should not be able to change the settings by using mvn -s $workspace/some_setting_with_external_repo.xml -DskipTests=true But they can just change the pom to skip tests anyway... You have a false sense of security... That was a bit of a bad example - but actually if they want to skip tests in the POM then that is 100% ok - as we know that the tests were not run on a specific build. And if they want to use a different settings... Invoker and an alternative pom file. But you are assuming my maven enforcer rules etc. are the only line of defence here. The MRM can also play an important part :-) Besides that can you configure things that are not reporters? e.g. wipe out workspace, always checkout a fresh copy, enable a release plugin... Plus you can just watch what shit they are committing... You need to do that with the poms anyway No I can't (and actually I don't). If I could do that then we wouldn't need the Template plugin as I could watch all Jenkins job creation :-) You are correct in that there is a little bit of an arms race going on - but most of this is not actively trying to create non-repeatable builds - it's just people not always thinking things through and the system can probably automatically pick up 95+% of that. There are several thousand projects+branches - it would take a full time person to watch all of that - you could say that this could be somewhat automated - but even that has human overhead to setup these jobs when new projects are added, maintain mapping of project/branch to user+manager mapping etc... but at the same time its nice that you just branch and get a job (from say a job that's created from some kind of template, and that should allow the user to specify the properties exposed by that template only...) (you haven't yet beaten my addiction to the maven job type...) I'm not done... There are more tricks up my sleeve -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
On 4 October 2013 08:42, teilo teilo+goo...@teilo.net wrote: On Thursday, 3 October 2013 20:37:27 UTC+1, Stephen Connolly wrote: On Thursday, 3 October 2013, teilo wrote: Hi Stephen, Is the literate plugin going to be the only route into the multi-branch job? I am sure somebody may use the branch api to implement other types... I have a freestyle multi branch but there is just too many build differences for it to be useful and a ton of UI glitches because plugins assume they are owned by ? extends Job Reason being for enterprisy software we need to enforce things in a build/release so I can't let my users run abitrary maven invocations that change the build (and make it unreproduceable). e.g. they should not be able to change the settings by using mvn -s $workspace/some_setting_with_**external_repo.xml -DskipTests=true But they can just change the pom to skip tests anyway... You have a false sense of security... That was a bit of a bad example - but actually if they want to skip tests in the POM then that is 100% ok - as we know that the tests were not run on a specific build. And if they want to use a different settings... Invoker and an alternative pom file. But you are assuming my maven enforcer rules etc. are the only line of defence here. The MRM can also play an important part :-) Yes which is why I have another trick up my sleeve as part of my make maven better on jenkins and get rid of the ugly aberration that is the Maven project type plan... Besides that can you configure things that are not reporters? e.g. wipe out workspace, That is something that does not make sense in SCM, so that is configured from Jenkins always checkout a fresh copy, As for wipe out workspace enable a release plugin... That is awaiting the tasks support that KK has said he will help write... basically the way this will work is you will enable a branch property that defines the promotion tasks to support for that branch... you will specify the heading keyword to identify the steps for that task and the environment to run the task on... so to enable releasing from Maven you would do something like # To make a release mvn release:prepare release:perform -B and then in jenkins you just tell jenkins that, e.g. the master branch has a release task with the keyword release in the heading Thus you will only be able to cut releases from the master branch. Plus you can just watch what shit they are committing... You need to do that with the poms anyway No I can't (and actually I don't). If I could do that then we wouldn't need the Template plugin as I could watch all Jenkins job creation :-) You are correct in that there is a little bit of an arms race going on - but most of this is not actively trying to create non-repeatable builds - it's just people not always thinking things through and the system can probably automatically pick up 95+% of that. What is a non-repeatable build in this context? The SCM revision will still be buildable if Jenkins built it once before. Or is it that you are worries about people injecting alternative settings.xml in the build command? We are nowhere near it works on my machine land, though I suspect you will need to see my maven improvement plans before you fully believe me There are several thousand projects+branches - it would take a full time person to watch all of that - you could say that this could be somewhat automated - but even that has human overhead to setup these jobs when new projects are added, maintain mapping of project/branch to user+manager mapping etc... but at the same time its nice that you just branch and get a job (from say a job that's created from some kind of template, and that should allow the user to specify the properties exposed by that template only...) (you haven't yet beaten my addiction to the maven job type...) I'm not done... There are more tricks up my sleeve -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
But you are assuming my maven enforcer rules etc. are the only line of defence here. The MRM can also play an important part :-) Yes which is why I have another trick up my sleeve as part of my make maven better on jenkins and get rid of the ugly aberration that is the Maven project type plan... I guess that is the trick I have been waiting for for a while... You've made a lot out of this - I'm expecting the moon on a stick solution :-) Besides that can you configure things that are not reporters? e.g. wipe out workspace, That is something that does not make sense in SCM, so that is configured from Jenkins always checkout a fresh copy, As for wipe out workspace enable a release plugin... That is awaiting the tasks support that KK has said he will help write... basically the way this will work is you will enable a branch property that defines the promotion tasks to support for that branch... you will specify the heading keyword to identify the steps for that task and the environment to run the task on... so to enable releasing from Maven you would do something like # To make a release mvn release:prepare release:perform -B and then in jenkins you just tell jenkins that, e.g. the master branch has a release task with the keyword release in the heading Thus you will only be able to cut releases from the master branch. Plus you can just watch what shit they are committing... You need to do that with the poms anyway No I can't (and actually I don't). If I could do that then we wouldn't need the Template plugin as I could watch all Jenkins job creation :-) You are correct in that there is a little bit of an arms race going on - but most of this is not actively trying to create non-repeatable builds - it's just people not always thinking things through and the system can probably automatically pick up 95+% of that. What is a non-repeatable build in this context? I should have also included traceable so replace with non-repeatable non-traceable it is a build that we can't trace back to the source code, or for which if we checked it out onto a clean machine setup with the correct OS/java/maven could not run mvn install and have identical binaries in the future (we record the JDK version and maven version used to build as well as the build host which will tell us the OS). Obviously there could be cases where some bad unit tests have some dates in them and these could fail if time has moved on - but they should be easily identifiable) The SCM revision will still be buildable if Jenkins built it once before. Not true. If you change the settings, or disable enforcer rules etc you can add a external repository. As we all know some of these external maven repositories have a habit of being here one day and gone the next. That is why we force everything via our MRM which will keep every single release it downloads forever to handle just this case. There are also times when the upstream repo replaces a release version (even sonatype has let this happen on their hosted repositories in the past!) So just because you built something today doesn't mean that the dependencies/plugins you need to build it tomorrow will still be around and at the same place. There are also occasions where someone sets a release version on trunk and would let jenkins mvn deploy - this could be ok as far as the MRM is concerned yet there is no tag in SCM. As there is no tag there it may be on a branch that is a personal branch or a throwaway branch that can be deleted (e.g. you allow deleteion of personal/** but not releases/** - but don;t allow deletion/redefinition of tags) Or is it that you are worries about people injecting alternative settings.xml in the build command? That would be one of my big concerns with this. (Sonar being another root of all evil..) this setup would also allow users to have jars in SCM that they mvn install:installFile... (with maven2 you could have done this with system scope - but the enforcer rules should have prevented this). The above isn't about reproduceability - but to make sure that people don;t check in jars to SCM - and that they go via the 3rd party reposiroty and have their licence/useage tracked. All our main source build jobs use the same template that allows you to specify the following, 1) source location 2) users to email 3) java version 4a) maven version 4b) number of threads (-T...) 5) If you want any findbugs violations to mark the build as unstable 6) if you want any checkstyle violations to mark the build as unstable 7) slave restriction With just that you have a whole host of plugins configured - and just managed. You get reports even if you choose to ignore them so the commands to run are (for a ommit build) always the same mvn install checkstyle:checkstyle findbugs:findbugs, and it prevents you from doing a lot of stuff like adding
Re: Adventurous users wanted! Literate multi-branch project type
On 4 October 2013 09:39, teilo teilo+goo...@teilo.net wrote: But you are assuming my maven enforcer rules etc. are the only line of defence here. The MRM can also play an important part :-) Yes which is why I have another trick up my sleeve as part of my make maven better on jenkins and get rid of the ugly aberration that is the Maven project type plan... I guess that is the trick I have been waiting for for a while... You've made a lot out of this - I'm expecting the moon on a stick solution :-) Besides that can you configure things that are not reporters? e.g. wipe out workspace, That is something that does not make sense in SCM, so that is configured from Jenkins always checkout a fresh copy, As for wipe out workspace enable a release plugin... That is awaiting the tasks support that KK has said he will help write... basically the way this will work is you will enable a branch property that defines the promotion tasks to support for that branch... you will specify the heading keyword to identify the steps for that task and the environment to run the task on... so to enable releasing from Maven you would do something like # To make a release mvn release:prepare release:perform -B and then in jenkins you just tell jenkins that, e.g. the master branch has a release task with the keyword release in the heading Thus you will only be able to cut releases from the master branch. Plus you can just watch what shit they are committing... You need to do that with the poms anyway No I can't (and actually I don't). If I could do that then we wouldn't need the Template plugin as I could watch all Jenkins job creation :-) You are correct in that there is a little bit of an arms race going on - but most of this is not actively trying to create non-repeatable builds - it's just people not always thinking things through and the system can probably automatically pick up 95+% of that. What is a non-repeatable build in this context? I should have also included traceable so replace with non-repeatable non-traceable it is a build that we can't trace back to the source code, or for which if we checked it out onto a clean machine setup with the correct OS/java/maven could not run mvn install and have identical binaries in the future (we record the JDK version and maven version used to build as well as the build host which will tell us the OS). Obviously there could be cases where some bad unit tests have some dates in them and these could fail if time has moved on - but they should be easily identifiable) The SCM revision will still be buildable if Jenkins built it once before. Not true. If you change the settings, or disable enforcer rules etc you can add a external repository. As we all know some of these external maven repositories have a habit of being here one day and gone the next. That is why we force everything via our MRM which will keep every single release it downloads forever to handle just this case. There are also times when the upstream repo replaces a release version (even sonatype has let this happen on their hosted repositories in the past!) So just because you built something today doesn't mean that the dependencies/plugins you need to build it tomorrow will still be around and at the same place. There are also occasions where someone sets a release version on trunk and would let jenkins mvn deploy - this could be ok as far as the MRM is concerned yet there is no tag in SCM. As there is no tag there it may be on a branch that is a personal branch or a throwaway branch that can be deleted (e.g. you allow deleteion of personal/** but not releases/** - but don;t allow deletion/redefinition of tags) Or is it that you are worries about people injecting alternative settings.xml in the build command? That would be one of my big concerns with this. (Sonar being another root of all evil..) this setup would also allow users to have jars in SCM that they mvn install:installFile... (with maven2 you could have done this with system scope - but the enforcer rules should have prevented this). The above isn't about reproduceability - but to make sure that people don;t check in jars to SCM - and that they go via the 3rd party reposiroty and have their licence/useage tracked. All our main source build jobs use the same template that allows you to specify the following, 1) source location 2) users to email 3) java version 4a) maven version 4b) number of threads (-T...) 5) If you want any findbugs violations to mark the build as unstable 6) if you want any checkstyle violations to mark the build as unstable 7) slave restriction With just that you have a whole host of plugins configured - and just managed. You get reports even if you choose to ignore them so the commands to run are (for a ommit build) always the same mvn install checkstyle:checkstyle findbugs:findbugs, and it
Re: Adventurous users wanted! Literate multi-branch project type
I think the idea is great and can see this being fantastic for open source, or where you have a smaller company/team where you can check every commit to the build settings, I'm just not sure I could use it in an enterprise without being bitten by its ultimate flexibility (which is one reason why we use templates - but that gets us a plethora of jobs for the dozens of branches in each project!) Oh way cool you've just given me an idea for another enterprise plugin: multi-branch-templates plugin That should be easy... and because it's templates we don't have the UI glitches we see with my (currently closed source) free-style multi-branch plugin https://rm.cloudbees.com/issues/2111 That should make you happy... now just to convince Harpreet to put it on the backlog... feel free to file a ZD ;-) Raised ZD#13606 -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
Hi Stephen, Is the literate plugin going to be the only route into the multi-branch job? Reason being for enterprisy software we need to enforce things in a build/release so I can't let my users run abitrary maven invocations that change the build (and make it unreproduceable). e.g. they should not be able to change the settings by using mvn -s $workspace/some_setting_with_external_repo.xml -DskipTests=true but at the same time its nice that you just branch and get a job (from say a job that's created from some kind of template, and that should allow the user to specify the properties exposed by that template only...) (you haven't yet beaten my addiction to the maven job type...) /James On Friday, 20 September 2013 10:16:47 UTC+1, Stephen Connolly wrote: Ok! This is the first bit of noise about this. I'll be writing up a series of blog posts around this, but as I just got everything OSS I thought that some of the more adventurous amongst you may want to start playing with it now. To play with this you need to do the following: 1. Checkout and build (mvn install) the branch-api-plugin 2. Checkout and build (mvn package) the literate-plugin 3a. Checkout and build (mvn package) the git plugin (either the master or the refactoring branch... pick your poison) 3b. Checkout and build (mvn package) the subversion plugin (the refactoring branch) 3c. Checkout and build (mvn package) the mercurial plugin In your Jenkins 1.509+ install the three (or more) plugins that you have just built You should now be able to create literate multi-branch projects. To try it out. In your SCM system create a project. In the root of the project put the following two files: $ touch .cloudbees.md cat - README.md EOF Hello World project == How to Build -- echo 'Hello world' EOF Checkin these two files. Create a literate multi-branch project with your project as a source. Trigger the indexing. You should see a sub-project for the main branch of the project. *NOW* go and fork your main branch into another branch. Trigger indexing again... oh look that branch has a project too. Have fun. The 10 best bug reports will be getting at least a T-shirt from CloudBees, but I am hoping to improve the swag that I can offer. -Stephen P.S. There will be an update centre that allows people to pull this without building themselves... and there will be a blog post later today detailing more of the fun you can do! P.P.S. The aim is to have enough people test this that it can be considered GA ready for JUC in late Oct 2013 P.P.P.S. Many thanks to my employers (CloudBees) for funding the development of this fully open source (MIT license) feature for Jenkins... the only cost is that the default marker file is called .cloudbees.md! -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
I've not had a chance to work with the plugin yet, but did notice on a freestyle job the Export to literate-style does not show the image correctly. It is a broken image. The HTML for the image is as follows: img height=24 style=margin: 2px; alt= width=24 src=/static/70af5004/plugin/cloudbees-multibranch-plugin/images/24x24/literate-export.png Looks like https://github.com/jenkinsci/literate-plugin/blob/master/src/main/java/org/cloudbees/literate/jenkins/MigrateFreeStyleAction.java#L91 needs to be updated. -- Larry On Fri, Sep 20, 2013 at 3:16 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Ok! This is the first bit of noise about this. I'll be writing up a series of blog posts around this, but as I just got everything OSS I thought that some of the more adventurous amongst you may want to start playing with it now. To play with this you need to do the following: 1. Checkout and build (mvn install) the branch-api-plugin 2. Checkout and build (mvn package) the literate-plugin 3a. Checkout and build (mvn package) the git plugin (either the master or the refactoring branch... pick your poison) 3b. Checkout and build (mvn package) the subversion plugin (the refactoring branch) 3c. Checkout and build (mvn package) the mercurial plugin In your Jenkins 1.509+ install the three (or more) plugins that you have just built You should now be able to create literate multi-branch projects. To try it out. In your SCM system create a project. In the root of the project put the following two files: $ touch .cloudbees.md cat - README.md EOF Hello World project == How to Build -- echo 'Hello world' EOF Checkin these two files. Create a literate multi-branch project with your project as a source. Trigger the indexing. You should see a sub-project for the main branch of the project. *NOW* go and fork your main branch into another branch. Trigger indexing again... oh look that branch has a project too. Have fun. The 10 best bug reports will be getting at least a T-shirt from CloudBees, but I am hoping to improve the swag that I can offer. -Stephen P.S. There will be an update centre that allows people to pull this without building themselves... and there will be a blog post later today detailing more of the fun you can do! P.P.S. The aim is to have enough people test this that it can be considered GA ready for JUC in late Oct 2013 P.P.P.S. Many thanks to my employers (CloudBees) for funding the development of this fully open source (MIT license) feature for Jenkins... the only cost is that the default marker file is called .cloudbees.md! -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Fwd: Adventurous users wanted! Literate multi-branch project type
Hi Stephen, as you have noticed, I started to play with the plugin, I totally agree that it has tremendous potential and this will be the foundation for many improvements in Jenkins. I have an open question concerning how to handle several 'ways' of building the same project. In the given examples, there are 'build' and 'release' mentioned. On a broader perspective, for a given project, you could have a build, test, integration-test jobs. These seem different from the 'environments' which relate to what is done with matrix jobs. How do you think this could be done with literate? I have seen build profiles, but these seem to apply only to defined agents, I don't think they are mentioned in build definition. There is also a chaining problem (usually you'd like build - test - integration-test in sequence) In any case, this is really great stuff, this will be a revolution when this hits mainstream ;) Vincent 2013/9/21 Jesse Glick jgl...@cloudbees.com On Fri, Sep 20, 2013 at 7:38 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: This update center: http://updates.jenkins-ci.org/experimental/ contains the alpha and beta releases In case it was not clear, there are already beta releases of the five aforementioned plugins on this UC, so you do not need to build from source if you just want to play around. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
On 25 September 2013 15:22, Vincent Latombe vincent.lato...@gmail.comwrote: Hi Stephen, as you have noticed, I started to play with the plugin, I totally agree that it has tremendous potential and this will be the foundation for many improvements in Jenkins. I have an open question concerning how to handle several 'ways' of building the same project. In the given examples, there are 'build' and 'release' mentioned. Well there are three aspects I see to this: 1. The tasks aspect. Wherein the job says We support the following 'task' sections: ... this will result in essentially build promotions being available for each branch 2. The marker file aspect. Since each job can define a different marker file base-name, you could use different marker files for different build flavours. 3. I have yet to add the UI, but you can change the keyword(s) for the environments and build sections, so you could have a integration test environment section and a integration test section in a separate job. I am open to suggestions for other alternatives. On a broader perspective, for a given project, you could have a build, test, integration-test jobs. These seem different from the 'environments' which relate to what is done with matrix jobs. How do you think this could be done with literate? I have seen build profiles, but these seem to apply only to defined agents, I don't think they are mentioned in build definition. There is also a chaining problem (usually you'd like build - test - integration-test in sequence) w.r.t. the chaining problem, I believe that the interrelationship between Jenkins jobs is not something that should be maintained in the source code SCM... (now if you get into complex build pipelines, the pipeline should be in SCM, but not the SCM of any one node in the pipeline) Thus I think that the interrelationship between Jenkins jobs should be expressed within Jenkins itself. I see Branch Properties to support the traditional upstream/downstream relationship between jobs (only reflecting the branch and (since we have it with multi-branch) the SCM revision) In any case, this is really great stuff, this will be a revolution when this hits mainstream ;) Yes, that is my belief too, but you can see that it has a few small rough edges right now! Vincent 2013/9/21 Jesse Glick jgl...@cloudbees.com On Fri, Sep 20, 2013 at 7:38 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: This update center: http://updates.jenkins-ci.org/experimental/ contains the alpha and beta releases In case it was not clear, there are already beta releases of the five aforementioned plugins on this UC, so you do not need to build from source if you just want to play around. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
good catch! http://developer-blog.cloudbees.com/2013/09/a-brief-history-of-literate-builds.htmlhas the history of this plugin... which is where that bit of code came from On 25 September 2013 15:21, Larry Shatzer, Jr. lar...@gmail.com wrote: I've not had a chance to work with the plugin yet, but did notice on a freestyle job the Export to literate-style does not show the image correctly. It is a broken image. The HTML for the image is as follows: img height=24 style=margin: 2px; alt= width=24 src=/static/70af5004/plugin/cloudbees-multibranch-plugin/images/24x24/literate-export.png Looks like https://github.com/jenkinsci/literate-plugin/blob/master/src/main/java/org/cloudbees/literate/jenkins/MigrateFreeStyleAction.java#L91 needs to be updated. -- Larry On Fri, Sep 20, 2013 at 3:16 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Ok! This is the first bit of noise about this. I'll be writing up a series of blog posts around this, but as I just got everything OSS I thought that some of the more adventurous amongst you may want to start playing with it now. To play with this you need to do the following: 1. Checkout and build (mvn install) the branch-api-plugin 2. Checkout and build (mvn package) the literate-plugin 3a. Checkout and build (mvn package) the git plugin (either the master or the refactoring branch... pick your poison) 3b. Checkout and build (mvn package) the subversion plugin (the refactoring branch) 3c. Checkout and build (mvn package) the mercurial plugin In your Jenkins 1.509+ install the three (or more) plugins that you have just built You should now be able to create literate multi-branch projects. To try it out. In your SCM system create a project. In the root of the project put the following two files: $ touch .cloudbees.md cat - README.md EOF Hello World project == How to Build -- echo 'Hello world' EOF Checkin these two files. Create a literate multi-branch project with your project as a source. Trigger the indexing. You should see a sub-project for the main branch of the project. *NOW* go and fork your main branch into another branch. Trigger indexing again... oh look that branch has a project too. Have fun. The 10 best bug reports will be getting at least a T-shirt from CloudBees, but I am hoping to improve the swag that I can offer. -Stephen P.S. There will be an update centre that allows people to pull this without building themselves... and there will be a blog post later today detailing more of the fun you can do! P.P.S. The aim is to have enough people test this that it can be considered GA ready for JUC in late Oct 2013 P.P.P.S. Many thanks to my employers (CloudBees) for funding the development of this fully open source (MIT license) feature for Jenkins... the only cost is that the default marker file is called .cloudbees.md! -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
Yes I normally do something similar. But they are fixed now and the plugin
will not be getting renamed again I suspect!
On 25 September 2013 16:24, Vincent Latombe vincent.lato...@gmail.comwrote:
Same problem with
https://github.com/jenkinsci/literate-plugin/blob/master/src/main/java/org/cloudbees/literate/jenkins/ReadMeAction.java#L79
It's slightly off-topic, but it shows a portability pattern that could be
solved by core.
In my plugins, I use
class Util {
private PluginWrapper plugin;
public static String getImagesURL() {
if (plugin == null) {
plugin =
Jenkins.getInstance().getPluginManager().whichPlugin(Util.class);
}
return /plugin/ + plugin.getShortName() + /images;
}
}
to get portable path to access images. Maybe this could be generalized ?
Vincent
2013/9/25 Stephen Connolly stephen.alan.conno...@gmail.com
good catch!
http://developer-blog.cloudbees.com/2013/09/a-brief-history-of-literate-builds.htmlhas
the history of this plugin... which is where that bit of code came from
On 25 September 2013 15:21, Larry Shatzer, Jr. lar...@gmail.com wrote:
I've not had a chance to work with the plugin yet, but did notice on a
freestyle job the Export to literate-style does not show the image
correctly. It is a broken image. The HTML for the image is as follows:
img height=24 style=margin: 2px; alt= width=24
src=/static/70af5004/plugin/cloudbees-multibranch-plugin/images/24x24/literate-export.png
Looks like
https://github.com/jenkinsci/literate-plugin/blob/master/src/main/java/org/cloudbees/literate/jenkins/MigrateFreeStyleAction.java#L91
needs
to be updated.
-- Larry
On Fri, Sep 20, 2013 at 3:16 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Ok!
This is the first bit of noise about this. I'll be writing up a series
of blog posts around this, but as I just got everything OSS I thought that
some of the more adventurous amongst you may want to start playing with it
now.
To play with this you need to do the following:
1. Checkout and build (mvn install) the branch-api-plugin
2. Checkout and build (mvn package) the literate-plugin
3a. Checkout and build (mvn package) the git plugin (either the master
or the refactoring branch... pick your poison)
3b. Checkout and build (mvn package) the subversion plugin (the
refactoring branch)
3c. Checkout and build (mvn package) the mercurial plugin
In your Jenkins 1.509+ install the three (or more) plugins that you
have just built
You should now be able to create literate multi-branch projects.
To try it out.
In your SCM system create a project. In the root of the project put the
following two files:
$ touch .cloudbees.md
cat - README.md EOF
Hello World project
==
How to Build
--
echo 'Hello world'
EOF
Checkin these two files. Create a literate multi-branch project with
your project as a source. Trigger the indexing. You should see a
sub-project for the main branch of the project.
*NOW* go and fork your main branch into another branch.
Trigger indexing again... oh look that branch has a project too.
Have fun.
The 10 best bug reports will be getting at least a T-shirt from
CloudBees, but I am hoping to improve the swag that I can offer.
-Stephen
P.S. There will be an update centre that allows people to pull this
without building themselves... and there will be a blog post later today
detailing more of the fun you can do!
P.P.S. The aim is to have enough people test this that it can be
considered GA ready for JUC in late Oct 2013
P.P.P.S. Many thanks to my employers (CloudBees) for funding the
development of this fully open source (MIT license) feature for Jenkins...
the only cost is that the default marker file is called .cloudbees.md
!
--
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-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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-dev+unsubscr...@googlegroups.com.
For more options, visit
Adventurous users wanted! Literate multi-branch project type
Ok! This is the first bit of noise about this. I'll be writing up a series of blog posts around this, but as I just got everything OSS I thought that some of the more adventurous amongst you may want to start playing with it now. To play with this you need to do the following: 1. Checkout and build (mvn install) the branch-api-plugin 2. Checkout and build (mvn package) the literate-plugin 3a. Checkout and build (mvn package) the git plugin (either the master or the refactoring branch... pick your poison) 3b. Checkout and build (mvn package) the subversion plugin (the refactoring branch) 3c. Checkout and build (mvn package) the mercurial plugin In your Jenkins 1.509+ install the three (or more) plugins that you have just built You should now be able to create literate multi-branch projects. To try it out. In your SCM system create a project. In the root of the project put the following two files: $ touch .cloudbees.md cat - README.md EOF Hello World project == How to Build -- echo 'Hello world' EOF Checkin these two files. Create a literate multi-branch project with your project as a source. Trigger the indexing. You should see a sub-project for the main branch of the project. *NOW* go and fork your main branch into another branch. Trigger indexing again... oh look that branch has a project too. Have fun. The 10 best bug reports will be getting at least a T-shirt from CloudBees, but I am hoping to improve the swag that I can offer. -Stephen P.S. There will be an update centre that allows people to pull this without building themselves... and there will be a blog post later today detailing more of the fun you can do! P.P.S. The aim is to have enough people test this that it can be considered GA ready for JUC in late Oct 2013 P.P.P.S. Many thanks to my employers (CloudBees) for funding the development of this fully open source (MIT license) feature for Jenkins... the only cost is that the default marker file is called .cloudbees.md! -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
Here's some docs that Michael Neale wrote up: https://developer.cloudbees.com/bin/view/DEV/LiterateBuilds On 20 September 2013 10:16, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Ok! This is the first bit of noise about this. I'll be writing up a series of blog posts around this, but as I just got everything OSS I thought that some of the more adventurous amongst you may want to start playing with it now. To play with this you need to do the following: 1. Checkout and build (mvn install) the branch-api-plugin 2. Checkout and build (mvn package) the literate-plugin 3a. Checkout and build (mvn package) the git plugin (either the master or the refactoring branch... pick your poison) 3b. Checkout and build (mvn package) the subversion plugin (the refactoring branch) 3c. Checkout and build (mvn package) the mercurial plugin In your Jenkins 1.509+ install the three (or more) plugins that you have just built You should now be able to create literate multi-branch projects. To try it out. In your SCM system create a project. In the root of the project put the following two files: $ touch .cloudbees.md cat - README.md EOF Hello World project == How to Build -- echo 'Hello world' EOF Checkin these two files. Create a literate multi-branch project with your project as a source. Trigger the indexing. You should see a sub-project for the main branch of the project. *NOW* go and fork your main branch into another branch. Trigger indexing again... oh look that branch has a project too. Have fun. The 10 best bug reports will be getting at least a T-shirt from CloudBees, but I am hoping to improve the swag that I can offer. -Stephen P.S. There will be an update centre that allows people to pull this without building themselves... and there will be a blog post later today detailing more of the fun you can do! P.P.S. The aim is to have enough people test this that it can be considered GA ready for JUC in late Oct 2013 P.P.P.S. Many thanks to my employers (CloudBees) for funding the development of this fully open source (MIT license) feature for Jenkins... the only cost is that the default marker file is called .cloudbees.md! -- 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-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
