Advertisement
Guest User

Untitled

a guest
Aug 23rd, 2019
84
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.18 KB | None | 0 0
  1. # verbose output
  2. `-Sdeps '{:aliases {:verbose {:verbose true}}}' -A:verbose`
  3.  
  4.  
  5.  
  6. # timing the download of dependencies if there are issues
  7. `time clj -Spath -Sforce`
  8.  
  9.  
  10. # Switching to a monorepo
  11. All internal libraries are `:local/root`. Makes working in the REPL great (elaborate)
  12.  
  13. Constraints when switching:
  14.  
  15. - We use CircleCI for CI/CD. There's no support for monorepos with CircleCI. This leads to longer build times - every project runs through its test steps with every push. We recently switched to their new unlimited parallelism plan which has been quite helpful in getting CI time down.
  16.  
  17. - CI configuration was moved into a set of clojure files because it became far too tedious messing around with YAML with the number of projects we have. This does, unfortunately, mean that CI config needs to be manually generated with a command every time you change the CI clojure files.
  18.  
  19. - We have a small service diff library that detects when a particular service's code, deps.edn, or `:local/root` deps have changed. That ensures a service won't get deployed on every push.
  20.  
  21. - We don't have a great way to have a common deps.edn across all projects. This would be quite useful for things like: global exclusions (when supported), overriding certain library versions, common aliases, etc. Ideally there'd be some way to just pass in N number of deps.edn files to `clj` and have it merge those in. Any editor environment would also need to have some way to select which deps.edn files to use (like CALVA)
  22.  
  23. - We don't have a good way to run commands across all projects or only in a certain project. For example, I'd like to be able to do something like: `monorepo my-service uberjar`.
  24.  
  25. - Ensure consistant alases for running tests and other tasks
  26. Different libraries & services run tests with a different set of aliases. Every time we want to run the tests for a project, you need to go to the projects README (or check the CI config) and determine which aliases to use to run the tests. Either the aforementioned "command runner" or a way to combine aliases somehow would make this much better.
  27.  
  28. Overall, this workflow is *far* better than having individual repos and constantly needing to restart the REPL when working across projects.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement