Re: Rusts Upgrades
Nathan, I wasn’t concerned with Github per se but the CI server compiling/running arbitrary code should some library’s repo get pwnd in some way or that a rogue library could make it into the list of repos to build in the proposed system. A hand curated list of repos would mitigate this last concern. I suppose CircleCI/Travis have this figured out (sandboxes?) given that they already run arbitrary code via tests. I’ve not used any of the cloud-based CI services, just in-house installations that are tightly controlled. Never mind... I think I’ve left my paranoia dial set to 11 after reading about remote Spectre attacks. Alan On Jul 30, 2018, at 1:01 PM, Nathan Fisher wrote: If it’s run on CircleCI or Travis and has readonly access to github, I wouldn’t be too concerned. The most frequent downloads API in Clojars is a good idea. Could use it as a basis for the hand rolled site for now and target it for automation in the future. I’m wondering how amenable/suitable it would be for the data to live in Clojars. On Mon, Jul 30, 2018 at 02:17, Alan Moore wrote: > Has anyone looked for vulnerabilities exposed by pulling random libraries > from github.com (or gitlab.com?) and building them? Macros come mind > (mined?!) Solved problem? AFAIK the Rust compiler can't run arbitrary code. > > Also instead of choosing "top-N projects on Github" I would begin with > the "most used projects on clojars" (# downloads in the last 12 months?) as > that might be a better metric/signal for prioritizing which libraries to > include. #RememberLeftPad > > Don't get me wrong, I like the idea. I'm just trying to think through the > possible hazards. > > Alan > > > On Friday, July 27, 2018 at 4:11:27 PM UTC-7, Nathan Fisher wrote: >> >> Hi Folks, >> >> Reading up the recent blog post “What is Rust 2018” and happened upon >> this; >> >> “We put in a lot of work to make upgrades painless; for example, we run a >> tool (called “crater”) before each Rust release that downloads every >> package on crates.io and attempts to build their code and run their >> tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html >> >> Seems an interesting idea and with Travis and other CI services providing >> free builds for OSS it doesn’t need to put a heavy financial/operational >> burden on a single entity. The main benefit for this is for people could >> get a quick centralised overview of compatibility of various projects and >> impending releases of Clojure. >> >> The main idea would be to have a grid view of the latest Clojure projects >> and their status against HEAD of Clojure (are snapshots pushed to a maven >> repo automatically as a result of a commit build?). Travis allows periodic >> builds so that could be used to trigger verification even when changes >> haven’t occurred. >> >> In terms of initial focus targeting the top-N projects on Github makes >> the most sense to me. The bit I’m still thinking through is providing some >> form of dashboard/aggregation without requiring a large investment in >> changes, infrastructure, etc. Might fit in nicely with something like >> clojars? Was thinking initially having a Github page with a table of >> projects and their build badges and talking to maintainers about >> configuring periodic builds with the latest Clojure snapshot. >> >> Thoughts? >> >> Cheers, >> Nathan >> -- >> - sent from my mobile >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- - sent from my mobile -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups "Clojure" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/krAB_1nJ6Hw/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the
Re: Rusts Upgrades
If it’s run on CircleCI or Travis and has readonly access to github, I wouldn’t be too concerned. The most frequent downloads API in Clojars is a good idea. Could use it as a basis for the hand rolled site for now and target it for automation in the future. I’m wondering how amenable/suitable it would be for the data to live in Clojars. On Mon, Jul 30, 2018 at 02:17, Alan Moore wrote: > Has anyone looked for vulnerabilities exposed by pulling random libraries > from github.com (or gitlab.com?) and building them? Macros come mind > (mined?!) Solved problem? AFAIK the Rust compiler can't run arbitrary code. > > Also instead of choosing "top-N projects on Github" I would begin with > the "most used projects on clojars" (# downloads in the last 12 months?) as > that might be a better metric/signal for prioritizing which libraries to > include. #RememberLeftPad > > Don't get me wrong, I like the idea. I'm just trying to think through the > possible hazards. > > Alan > > > On Friday, July 27, 2018 at 4:11:27 PM UTC-7, Nathan Fisher wrote: >> >> Hi Folks, >> >> Reading up the recent blog post “What is Rust 2018” and happened upon >> this; >> >> “We put in a lot of work to make upgrades painless; for example, we run a >> tool (called “crater”) before each Rust release that downloads every >> package on crates.io and attempts to build their code and run their >> tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html >> >> Seems an interesting idea and with Travis and other CI services providing >> free builds for OSS it doesn’t need to put a heavy financial/operational >> burden on a single entity. The main benefit for this is for people could >> get a quick centralised overview of compatibility of various projects and >> impending releases of Clojure. >> >> The main idea would be to have a grid view of the latest Clojure projects >> and their status against HEAD of Clojure (are snapshots pushed to a maven >> repo automatically as a result of a commit build?). Travis allows periodic >> builds so that could be used to trigger verification even when changes >> haven’t occurred. >> >> In terms of initial focus targeting the top-N projects on Github makes >> the most sense to me. The bit I’m still thinking through is providing some >> form of dashboard/aggregation without requiring a large investment in >> changes, infrastructure, etc. Might fit in nicely with something like >> clojars? Was thinking initially having a Github page with a table of >> projects and their build badges and talking to maintainers about >> configuring periodic builds with the latest Clojure snapshot. >> >> Thoughts? >> >> Cheers, >> Nathan >> -- >> - sent from my mobile >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- - sent from my mobile -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Rusts Upgrades
Has anyone looked for vulnerabilities exposed by pulling random libraries from github.com (or gitlab.com?) and building them? Macros come mind (mined?!) Solved problem? AFAIK the Rust compiler can't run arbitrary code. Also instead of choosing "top-N projects on Github" I would begin with the "most used projects on clojars" (# downloads in the last 12 months?) as that might be a better metric/signal for prioritizing which libraries to include. #RememberLeftPad Don't get me wrong, I like the idea. I'm just trying to think through the possible hazards. Alan On Friday, July 27, 2018 at 4:11:27 PM UTC-7, Nathan Fisher wrote: > > Hi Folks, > > Reading up the recent blog post “What is Rust 2018” and happened upon this; > > “We put in a lot of work to make upgrades painless; for example, we run a > tool (called “crater”) before each Rust release that downloads every > package on crates.io and attempts to build their code and run their > tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html > > Seems an interesting idea and with Travis and other CI services providing > free builds for OSS it doesn’t need to put a heavy financial/operational > burden on a single entity. The main benefit for this is for people could > get a quick centralised overview of compatibility of various projects and > impending releases of Clojure. > > The main idea would be to have a grid view of the latest Clojure projects > and their status against HEAD of Clojure (are snapshots pushed to a maven > repo automatically as a result of a commit build?). Travis allows periodic > builds so that could be used to trigger verification even when changes > haven’t occurred. > > In terms of initial focus targeting the top-N projects on Github makes the > most sense to me. The bit I’m still thinking through is providing some form > of dashboard/aggregation without requiring a large investment in changes, > infrastructure, etc. Might fit in nicely with something like clojars? Was > thinking initially having a Github page with a table of projects and their > build badges and talking to maintainers about configuring periodic builds > with the latest Clojure snapshot. > > Thoughts? > > Cheers, > Nathan > -- > - sent from my mobile > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Improving Library Status Visibility - was Re: Rusts Upgrades
Hi Alex, I don't think it would be necessary to scrape the Jenkins server too often. I speculate daily would be enough, hourly at most. Cheers, Nathan On Sun, 29 Jul 2018 at 03:42 Alex Miller wrote: > On contribs, I just added the emeddable build status plugin - that’s easy. > Migrating to Travis or Circle is not really a viable option based on my > last research on this. I’d be a little worried about adding a lot of > traffic that parsed the feeds. The box running Jenkins is already > underpowered and Is hate to add load just for that. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- - sent from my mobile -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Improving Library Status Visibility - was Re: Rusts Upgrades
On contribs, I just added the emeddable build status plugin - that’s easy. Migrating to Travis or Circle is not really a viable option based on my last research on this. I’d be a little worried about adding a lot of traffic that parsed the feeds. The box running Jenkins is already underpowered and Is hate to add load just for that. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Improving Library Status Visibility - was Re: Rusts Upgrades
There's basically 3 ways I could see addressing the Jenkins builds; 1. Install the Jenkins badge plugin ( https://wiki.jenkins.io/display/JENKINS/Embeddable+Build+Status+Plugin). 2. Migrate them to a SaaS provider like Travis or Circle. 3. Write a mapper that consumes the CC tray feed and outputs badges ( https://build.clojure.org/cc.xml?recursive). Given the limited bandwidth of the Cognitect folks 3 seems the most likely immediate solution. SaaS CI services provide CC Tray feeds ( https://api.travis-ci.org/repos/boot-clj/boot/cc.xml?branch=master) so using them as an aggregation method could be useful for 10s to 100s of projects. It lacks the commit revision but does have time and status which would be an incremental improvement over reams of pages with red and green badges. The SaaS providers provide aggregates up to the org level so I would want to use that for some of the more prolific Clojure community authors. That being said I don't see cc tray feeds as a scalable solution for all known libraries; a) it's dependent on author discipline in keeping a given branch green. b) it'll be a lot of potential requests to the SaaS providers and I'd like to be a good netizen. c) it's not a great way to isolate if a build broke due to a change in a Clojure SNAPSHOT. d) it requires community authors to "buy-in" to creating a periodic build against SNAPSHOT. Another approach I'm considering is using the org I created to host "sample projects" that can be community owned with periodic builds that exercise an "app" with common libraries and plugins against the latest Clojure SNAPSHOT builds. Something similar to how TechEmpower Web Framework Benchmarks has a number of authors submit a subproject to the repo ( https://github.com/TechEmpower/FrameworkBenchmarks). I plan to be fairly liberal in delegating admin access to the org to minimise bottlenecks and hopefully through that we could get good coverage that doesn't put too much demand on any one person. On Sat, 28 Jul 2018 at 21:44 Sean Corfield wrote: > Have you had any thoughts about incorporating Clojure Contrib projects? > They all have JVM/Clojure version grids as part of their Jenkins CI builds > but there isn’t a badge you could link to (although you could link to the > CI matrix page for each of them). They’re all tested against 1.9 / 1.10 and > several are tested against earlier versions too. E.g., > > > > https://build.clojure.org/job/core.cache-test-matrix/ > > https://build.clojure.org/job/data.priority-map-test-matrix/ > > https://build.clojure.org/job/java.jdbc-test-matrix/ > > > > Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > *From:* clojure@googlegroups.com on behalf of > Nathan Fisher > *Sent:* Saturday, July 28, 2018 4:11:13 PM > *To:* clojure@googlegroups.com > *Subject:* Re: Rusts Upgrades > > Hi Sean, > > It would be great if there was a general report that we could integrate > with Lein, Boot and anything else people happen to be using. > > I think for an MVP having folks update the status of their project > manually as it is verified might not be a bad first step. > > To that end I've created a Github page site here; > > - https://clojurestatus.github.io/dashboard/ > - https://github.com/ClojureStatus/dashboard > > I know it won't scale well to all the projects out there but if we can get > some of the major ones I think it could be useful. It'll probably need some > thought about how to improve the aggregate view, date of last build, etc. > > Cheers, > Nathan > > On Sat, 28 Jul 2018 at 19:50 Sean Corfield wrote: > >> I suspect quite a few Travis-enabled Clojure projects do full >> multi-version testing – but it’s hard to tell at a glance from Travis’s >> logs. For example, both HoneySQL and clj-time perform multi-version testing >> on Travis, but they do it through Leiningen aliases so there’s only one >> “build” – no grid of Clojure versions. I’d be interested in hearing of >> techniques to surface a grid of Clojure versions being tested on Travis. >> >> >> >> Note that clj-time is tested against a grid of JVM versions and that does >> surface on Travis – and I’ve just noticed that testing against Clojure >> master on OpenJDK 7 fails, presumably because Clojure master now requires >> Java 8? (but the Oracle JDK 7 build on Travis doesn’t fail). >> >> >> >> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN >> An Architect's View -- http://corfield.org/ >> >> "If you're not annoying somebody, you're not really alive." >> -- Margaret Atwood >> >> >>
RE: Rusts Upgrades
Have you had any thoughts about incorporating Clojure Contrib projects? They all have JVM/Clojure version grids as part of their Jenkins CI builds but there isn’t a badge you could link to (although you could link to the CI matrix page for each of them). They’re all tested against 1.9 / 1.10 and several are tested against earlier versions too. E.g., https://build.clojure.org/job/core.cache-test-matrix/ https://build.clojure.org/job/data.priority-map-test-matrix/ https://build.clojure.org/job/java.jdbc-test-matrix/ Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood From: clojure@googlegroups.com on behalf of Nathan Fisher Sent: Saturday, July 28, 2018 4:11:13 PM To: clojure@googlegroups.com Subject: Re: Rusts Upgrades Hi Sean, It would be great if there was a general report that we could integrate with Lein, Boot and anything else people happen to be using. I think for an MVP having folks update the status of their project manually as it is verified might not be a bad first step. To that end I've created a Github page site here; - https://clojurestatus.github.io/dashboard/ - https://github.com/ClojureStatus/dashboard I know it won't scale well to all the projects out there but if we can get some of the major ones I think it could be useful. It'll probably need some thought about how to improve the aggregate view, date of last build, etc. Cheers, Nathan On Sat, 28 Jul 2018 at 19:50 Sean Corfield mailto:s...@corfield.org>> wrote: I suspect quite a few Travis-enabled Clojure projects do full multi-version testing – but it’s hard to tell at a glance from Travis’s logs. For example, both HoneySQL and clj-time perform multi-version testing on Travis, but they do it through Leiningen aliases so there’s only one “build” – no grid of Clojure versions. I’d be interested in hearing of techniques to surface a grid of Clojure versions being tested on Travis. Note that clj-time is tested against a grid of JVM versions and that does surface on Travis – and I’ve just noticed that testing against Clojure master on OpenJDK 7 fails, presumably because Clojure master now requires Java 8? (but the Oracle JDK 7 build on Travis doesn’t fail). Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood From: clojure@googlegroups.com<mailto:clojure@googlegroups.com> mailto:clojure@googlegroups.com>> on behalf of Nathan Fisher mailto:nfis...@junctionbox.ca>> Sent: Friday, July 27, 2018 4:11:05 PM To: clojure@googlegroups.com<mailto:clojure@googlegroups.com> Subject: Rusts Upgrades Hi Folks, Reading up the recent blog post “What is Rust 2018” and happened upon this; “We put in a lot of work to make upgrades painless; for example, we run a tool (called “crater”) before each Rust release that downloads every package on crates.io<http://crates.io> and attempts to build their code and run their tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html Seems an interesting idea and with Travis and other CI services providing free builds for OSS it doesn’t need to put a heavy financial/operational burden on a single entity. The main benefit for this is for people could get a quick centralised overview of compatibility of various projects and impending releases of Clojure. The main idea would be to have a grid view of the latest Clojure projects and their status against HEAD of Clojure (are snapshots pushed to a maven repo automatically as a result of a commit build?). Travis allows periodic builds so that could be used to trigger verification even when changes haven’t occurred. In terms of initial focus targeting the top-N projects on Github makes the most sense to me. The bit I’m still thinking through is providing some form of dashboard/aggregation without requiring a large investment in changes, infrastructure, etc. Might fit in nicely with something like clojars? Was thinking initially having a Github page with a table of projects and their build badges and talking to maintainers about configuring periodic builds with the latest Clojure snapshot. Thoughts? Cheers, Nathan -- - sent from my mobile -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com<mailto:clojure@googlegroups.com> Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com<mailto:clojure%2bunsubscr...@googlegroups.com> For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You r
Re: Rusts Upgrades
Hi Sean, It would be great if there was a general report that we could integrate with Lein, Boot and anything else people happen to be using. I think for an MVP having folks update the status of their project manually as it is verified might not be a bad first step. To that end I've created a Github page site here; - https://clojurestatus.github.io/dashboard/ - https://github.com/ClojureStatus/dashboard I know it won't scale well to all the projects out there but if we can get some of the major ones I think it could be useful. It'll probably need some thought about how to improve the aggregate view, date of last build, etc. Cheers, Nathan On Sat, 28 Jul 2018 at 19:50 Sean Corfield wrote: > I suspect quite a few Travis-enabled Clojure projects do full > multi-version testing – but it’s hard to tell at a glance from Travis’s > logs. For example, both HoneySQL and clj-time perform multi-version testing > on Travis, but they do it through Leiningen aliases so there’s only one > “build” – no grid of Clojure versions. I’d be interested in hearing of > techniques to surface a grid of Clojure versions being tested on Travis. > > > > Note that clj-time is tested against a grid of JVM versions and that does > surface on Travis – and I’ve just noticed that testing against Clojure > master on OpenJDK 7 fails, presumably because Clojure master now requires > Java 8? (but the Oracle JDK 7 build on Travis doesn’t fail). > > > > Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > -- > *From:* clojure@googlegroups.com on behalf of > Nathan Fisher > *Sent:* Friday, July 27, 2018 4:11:05 PM > *To:* clojure@googlegroups.com > *Subject:* Rusts Upgrades > > Hi Folks, > > Reading up the recent blog post “What is Rust 2018” and happened upon this; > > “We put in a lot of work to make upgrades painless; for example, we run a > tool (called “crater”) before each Rust release that downloads every > package on crates.io and attempts to build their code and run their > tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html > > Seems an interesting idea and with Travis and other CI services providing > free builds for OSS it doesn’t need to put a heavy financial/operational > burden on a single entity. The main benefit for this is for people could > get a quick centralised overview of compatibility of various projects and > impending releases of Clojure. > > The main idea would be to have a grid view of the latest Clojure projects > and their status against HEAD of Clojure (are snapshots pushed to a maven > repo automatically as a result of a commit build?). Travis allows periodic > builds so that could be used to trigger verification even when changes > haven’t occurred. > > In terms of initial focus targeting the top-N projects on Github makes the > most sense to me. The bit I’m still thinking through is providing some form > of dashboard/aggregation without requiring a large investment in changes, > infrastructure, etc. Might fit in nicely with something like clojars? Was > thinking initially having a Github page with a table of projects and their > build badges and talking to maintainers about configuring periodic builds > with the latest Clojure snapshot. > > Thoughts? > > Cheers, > Nathan > -- > - sent from my mobile > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the G
RE: Rusts Upgrades
I suspect quite a few Travis-enabled Clojure projects do full multi-version testing – but it’s hard to tell at a glance from Travis’s logs. For example, both HoneySQL and clj-time perform multi-version testing on Travis, but they do it through Leiningen aliases so there’s only one “build” – no grid of Clojure versions. I’d be interested in hearing of techniques to surface a grid of Clojure versions being tested on Travis. Note that clj-time is tested against a grid of JVM versions and that does surface on Travis – and I’ve just noticed that testing against Clojure master on OpenJDK 7 fails, presumably because Clojure master now requires Java 8? (but the Oracle JDK 7 build on Travis doesn’t fail). Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood From: clojure@googlegroups.com on behalf of Nathan Fisher Sent: Friday, July 27, 2018 4:11:05 PM To: clojure@googlegroups.com Subject: Rusts Upgrades Hi Folks, Reading up the recent blog post “What is Rust 2018” and happened upon this; “We put in a lot of work to make upgrades painless; for example, we run a tool (called “crater”) before each Rust release that downloads every package on crates.io<http://crates.io> and attempts to build their code and run their tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html Seems an interesting idea and with Travis and other CI services providing free builds for OSS it doesn’t need to put a heavy financial/operational burden on a single entity. The main benefit for this is for people could get a quick centralised overview of compatibility of various projects and impending releases of Clojure. The main idea would be to have a grid view of the latest Clojure projects and their status against HEAD of Clojure (are snapshots pushed to a maven repo automatically as a result of a commit build?). Travis allows periodic builds so that could be used to trigger verification even when changes haven’t occurred. In terms of initial focus targeting the top-N projects on Github makes the most sense to me. The bit I’m still thinking through is providing some form of dashboard/aggregation without requiring a large investment in changes, infrastructure, etc. Might fit in nicely with something like clojars? Was thinking initially having a Github page with a table of projects and their build badges and talking to maintainers about configuring periodic builds with the latest Clojure snapshot. Thoughts? Cheers, Nathan -- - sent from my mobile -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com<mailto:clojure+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Rusts Upgrades
Sounds great! mfikes canary build for ClojureScript is similar. I do more targeted versions of this manually for certain kinds of changes. I don’t personally have time right now to build this but would love to have it. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Rusts Upgrades
Hi Folks, Reading up the recent blog post “What is Rust 2018” and happened upon this; “We put in a lot of work to make upgrades painless; for example, we run a tool (called “crater”) before each Rust release that downloads every package on crates.io and attempts to build their code and run their tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html Seems an interesting idea and with Travis and other CI services providing free builds for OSS it doesn’t need to put a heavy financial/operational burden on a single entity. The main benefit for this is for people could get a quick centralised overview of compatibility of various projects and impending releases of Clojure. The main idea would be to have a grid view of the latest Clojure projects and their status against HEAD of Clojure (are snapshots pushed to a maven repo automatically as a result of a commit build?). Travis allows periodic builds so that could be used to trigger verification even when changes haven’t occurred. In terms of initial focus targeting the top-N projects on Github makes the most sense to me. The bit I’m still thinking through is providing some form of dashboard/aggregation without requiring a large investment in changes, infrastructure, etc. Might fit in nicely with something like clojars? Was thinking initially having a Github page with a table of projects and their build badges and talking to maintainers about configuring periodic builds with the latest Clojure snapshot. Thoughts? Cheers, Nathan -- - sent from my mobile -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
