Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I jump on an existing scala project.
git pull && sbt compile test
Tests are failing.
Me: "Hey team, the tests are failing."
Team member: "That cannot be. They were passing for the the last run."
Me: "Did you run them locally?"
Team member: "No, on Jenkins. It was fine."
I check Jenkins.
Me: "What do you mean it's fine. The last successful deployment was on the end of May."
Team member: "The Pull Request checker always went through successfully."
I check how our Jenkins tasks are configured. It's true that the Pull Request Checker runs successfully yet due to a "minor misconfiguration" (aka "major fuckup") the Pull Request Checker only tests a tiny subset of the entire test suite.
Team members were were fine if their Pull Request got the "Success" notification on bitbucket's pull request page. And reviewers trusted that icon as well.
They never checked the master run of the Jenkins task. Where the tests were also failing for over a month.
I'm also highely confused how they did TDD. You know, writing a test first, making it green. (I hope they were just one specific test at a time assuming the others were green. The cynic in me assumes they outsourced running the tests to the Jenkins.)
Gnarf!
Team member having run the tests locally finally realizes: "The tests are broken. Gonna fix them."
Wow. Please, dear fellow developers: It does not kill you to run the entire test suite locally. Just do it. Treat the external test runners as a safety net. Yet always run the test suite locally first.4 -
The joy when tools do not have machine parseable output.
I'm looking at you SBT. My favorite pile of poo.
Remove the logging level from each line, then trim the line, then stab around inside the line with regexes, fishing for a possible match which hopefully is right...
Then stripping scala information like the object type, cause yeah...
A line can be for example "[info] Vector(File(...),File(...))" where info is the log level, Vector the wrapping sequence type, File(...) the wrapping element type and the string inside File(...) what yours truly needs.
As this is lot of shitty shabby string stabby stabby, we need to add a fuckton of boiler plate validation cause who knows what we just murdered.
To make it even more fucked up, a multi project project can produce different output for the same key.
:-)
Yeah. So we need to fix that too.
By the way, one can set log output to unbuffered in SBT.
Then the output is in random order :-)
Isn't that fun? Come on, you wanna poke that pile of shit, too.
The SBT plugin way is by the way no alternative, as I need a full Java environment for execution.
Which brings me to the last point:
For fucks sake, writing CLI applications in Java is so much bloody boilerplate code.
There's ugly and then there's the "please kill me" kind of level.
50 lines just to write a basic validation of argc / argv with commons cli.
That's 6 lines in python. Not kidding. :(
I currently hate everything.
Moments where the job sucks: When you have to hotwire two electric cables with high currency by giving both cables the blowjob of your life.3 -
ERROR [SUCCESSFUL ] org.scala-sbt.ivy#ivy;2.3.0-sbt-cb9cc189e9f3af519f9f102e6c5d446488ff6832!ivy.jar (13350ms)
I have a Successful error.4 -
🎶Today was a good day🎶
I finally got around to doing a task I'd had on my list for months
Plus: it's open source too!
https://github.com/muya/... -
Scala. The compiler is slow; sbt is buggy; too much syntactic sugar; implicits; cryptic; unreadable; and my biggest issue, symbols are reused and their use changes depending on how they are used, let's look at _:
As an existential type, as higher kind type parameter, as ignored variables, as ignored parameters, as ignored names of self types, as wildcard patterns, as wildcard imports, as hiding imports, for joining letters to punctuation, as assignment operators, as placeholder syntax, in partially applied functions, when converting call-by-name parameters to functions. -
I am lying down on the floor because I cannot figure out why this specs pass locally but repeatedly fail on the ci/cd pipeline. Literally done everything now I just want to lie here and sleep.3
-
Other build tools:
Here is a plugin, use it . Be done.
Scala Build Tool aka SBT:
Build your own plugin.
Everything is scala...
You can create by the way funny endless loops when using the wrong syntax - yet it might compile successfully. And then when you load the plugin, it works. Till it is evaluated - lazy evaluation for the fun.
Error messages are at best cryptic.
*If* you manage to get a working plugin and *if* it runs...
Surprise. Surprise.
You might need to parse the log output of SBT.
Another funny surprise: Log output isn't configurable. You can configure the log level. That's it.
So after a lot of pain stakingly putting together a fucking shitty plugin, you can now grind the rest of your brain with ...
sed.
Cause yeah. You can now use regex to parse an sbt build log and extract the necessary information.
:)
...
So....
Are we there?
Mwahahahhaa.
Only if you haven't forgotten to either disable colored output for SBT... Or take an extra mile with e.g. less -R.
Otherwise you have ASCII control characters in your file. :-)
After getting that shit to work, you now have finally a parseable build log.
Just took days instead of hours.
But that's SBT. :-)6 -
Installed JDK 14 and now everything has scattered. Cannot build, run or compile because of a plethora of config that must be updated. Literally want to die. Naturally, i would update my java home path to my old version in my bash_profile right? well tough shit. that didn't work either. Really fucking frustrated rn. Its like Java and sbt on my machine are at war.9
-
I just created a wolpertinger.
https://en.m.wikipedia.org/wiki/...
We have the problem that the number one build tool for scala / java is sbt.
Sbt sucks.
There are many nice plugins for maven.
Sbt can generate a POM from an SBT build.
But the plugins need to be set up, so the generated POM must be modified...
... a POM is XML.
So Python, Pexpect (as SBT needs a PTY and is very cranky regarding exiting properly and running non interactive)… POM XML modification....
Maven - Plugin run.
But we need to do this on... Larger scale.
So, as I'm a lazy mofo, I wrapped the python thingy in bash, mostly because it was simpler than dealing with async / threading in python. Just spawning per project...
So we have Bash, Python, Java, SBT / Maven, hand in hand....
... Is it normal to feel sorry for the build server?1 -
[worst part of a lang i love]
Not really the language, but i hate how sbt works, it compiles small projects instantly, but really slows down at a certain size, and it seems very deterministic. It stays the same speed after that, but once you hit that project size it just immediately starts being slow. -
Aka... How NOT to design a build system.
I must say that the winning award in that category goes without any question to SBT.
SBT is like trying to use a claymore mine to put some nails in a wall. It most likely will work somehow, but the collateral damage is extensive.
If you ask what build tool would possibly do this... It was probably SBT. Rant applies in general, but my arch nemesis is definitely SBT.
Let's start with the simplest thing: The data format you use to store.
Well. Data format. So use sth that can represent data or settings. Do *not* use a programming language, as this can neither be parsed / modified without an foreign interface or using the programming language itself...
Which is painful as fuck for automatisation, scripting and thus CI/CD.
Most important regarding the data format - keep it simple and stupid, yet precise and clean. Do not try to e.g. implement complex types - pain without gain. Plain old objects / structs, arrays, primitive types, simple as that.
No (severely) nested types, no lazy evaluation, just keep it as simple as possible. Build tools are complex enough, no need to feed the nightmare.
Data formats *must* have btw a proper encoding, looking at you Mr. XML. It should be standardized, so no crazy mfucking shit eating dev gets the idea to use whatever encoding they like.
Workflows. You know, things like
- update dependency
- compile stuff
- test run
- ...
Keep. Them. Simple.
Especially regarding settings and multiprojects.
http://lihaoyi.com/post/...
If you want to know how to absolutely never ever do it.
Again - keep. it. simple.
Make stuff configurable, allow the CLI tool used for building to pass this configuration in / allow setting of env variables. As simple as that.
Allow project settings - e.g. like repositories - to be set globally vs project wide.
Not simple are those tools who have...
- more knobs than documentation
- more layers than a wedding cake
- inheritance / merging of settings :(
- CLI and ENV have different names.
- CLI and ENV use different quoting
...
Which brings me to the CLI.
If your build tool has no CLI, it sucks. It just sucks. No discussion. It sucks, hmkay?
If your build tool has a CLI, but...
- it uses undocumented exit codes
- requires absurd or non-quoting (e.g. cannot parse quoted string)
- has unconfigurable logging
- output doesn't allow parsing
- CLI cannot be used for automatisation
It sucks, too... Again, no discussion.
Last point: Plugins and versioning.
I love plugins. And versioning.
Plugins can be a good choice to extend stuff, to scratch some specific itches.
Plugins are NOT an excuse to say: hey, we don't integrate any features or offer plugins by ourselves, go implement your own plugins for that.
That's just absurd.
(precondition: feature makes sense, like e.g. listing dependencies, checking for updates, etc - stuff that most likely anyone wants)
Versioning. Well. Here goes number one award to Node with it's broken concept of just installing multiple versions for the fuck of it.
Another award goes to tools without a locking file.
Another award goes to tools who do not support version ranges.
Yet another award goes to tools who do not support private repositories / mirrors via global configuration - makes fun bombing public mirrors to check for new versions available and getting rate limited to death.
In case someone has read so far and wonders why this rant came to be...
I've implemented a sort of on premise bot for updating dependencies for multiple build tools.
Won't be open sourced, as it is company property - but let me tell ya... Pain and pain are two different things. That was beyond pain.
That was getting your skin peeled off while being set on fire pain.
-.-5 -
This fucking ci/cd test keeps deleting my dB collections and I can't see what the fuck is going on. Circleci is of the devil and I won't stop fucking using it. I must crack this shit😡2
-
I have this sbt test that keeps failing on CI. Locally it works fine but soon as it goes through circle CI, shit gets fucked. Now when I incessantly keep rerunning the working flow without any change, it eventually passes and I am able to deploy. I have no idea wtf is happening or what to do about it. Isn't containerizatiom supposed to solve this whole worked on my machine conundrum? I am too unenthusiastic and numb to even feel anyway about this. Wish everything would end.5
Top Tags
Weekly Rant
View