This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-03-14
Channels
- # aleph (4)
- # announcements (10)
- # babashka (21)
- # beginners (67)
- # biff (7)
- # calva (4)
- # clojure (40)
- # clojure-europe (11)
- # clojure-gamedev (17)
- # clojure-losangeles (3)
- # clojure-madison (1)
- # clojure-nl (1)
- # clojure-norway (78)
- # clojure-uk (3)
- # clojurescript (83)
- # core-typed (18)
- # cursive (1)
- # datalevin (2)
- # datomic (2)
- # gratitude (2)
- # hyperfiddle (56)
- # introduce-yourself (1)
- # london-clojurians (1)
- # matcher-combinators (10)
- # membrane (161)
- # polylith (16)
- # portal (4)
- # reitit (4)
- # releases (3)
- # ring (2)
- # shadow-cljs (9)
- # squint (2)
- # timbre (10)
- # xtdb (14)
- # yamlscript (1)
@tengstrand FYI: we were using the lasted from main of polylith so far, and just discovered that no tests were run anymore. It looked like it didn't think any test needed to be run. I changed our deps to use the released version (0.2.19) and now it's working again. We haven't migrated anything with regards to workspace.edn file etc. by the way.
Interesting! Will have a look. Thanks.
I don't have time to look at this right now. Is it possible for you to go back, one commit at a time, and see which commit that caused the tests to stop running? @stefan.van.den.oord
And with pleasure; the commit where it starts failing is the last one: https://github.com/polyfy/polylith/commit/43416d912c3a3f51b6927dc5134c44a5214e39d0.
We're fine with using the released version by the way, so no time pressure from us! π
Okay, cool, thanks!
I have reverted the commit. Please take a look @stefan.van.den.oord and see if it works again.
The idea is that it should be possible to stay on the master
branch. I want at least some users to stay there, so that I get fast feedback if something breaks or can be improved. The master
branch has been historically stable, and I aim for it to continue to be so. I have started pushing changes to master more often, sometimes several times per day, which obviously made me overconfident. I will make sure to run the script that tests the entire system every time I push to master (takes about 15 minutes) which hopefully makes master
reliable again.
I'm also open to stay on master, but this way of testing is normally only used in CI, so if they are not run then we may not detect that. Or we need to wrap the call to poly test
, capture the output and verify that tests were actually run π
Do you have something like that in your CI?
I will take a closer look at this in the weekend, and see if I can reproduce the problem and maybe complement the CI build with more tests. We have the https://github.com/polyfy/polylith/blob/68b77399088c684f3f3b762f4abb207c760b8711/bb.edn#L59 task, that executes the poly
tool and generates output for the example in the documentation + against other workspaces (which takes about 15 minutes to run as I mentioned). The output vary slightly from time to time, because it uses the Polylith codebase itself (and other workspaces) as input to the poly
tool, which means I can't have that script in the CI build. The script is only executed manually, but it's a good one, and almost guarantees that all the commands executes as expected.
Itβs also used to keep the cljdoc up-to-date.
I just released https://cljdoc.org/d/polylith/clj-poly/0.2.20-SNAPSHOT/doc/readme #8. It includes a bug fix of the problem introduced in SNAPSHOT #7 (and reverted back to #6). The bug was created when I moved out code from the change
component to the new test
component. I've added a couple of new tests so hopefully it won't happen again. Please try it out @stefan.van.den.oord and others (that want to be on the master
branch).
With latest from main (453338e68a70432b0a61023f6483628692d5bb2d) the tests work. π
Hi guys! On dev time (development project) if two bricks use two different versions of a library, how use a particular version when I play with the repl?
I just released https://cljdoc.org/d/polylith/clj-poly/0.2.20-SNAPSHOT/doc/readme #8. It includes a bug fix of the problem introduced in SNAPSHOT #7 (and reverted back to #6). The bug was created when I moved out code from the change
component to the new test
component. I've added a couple of new tests so hopefully it won't happen again. Please try it out @stefan.van.den.oord and others (that want to be on the master
branch).