|
rotor posted:I'm not reallly aware of a better solution. rotor posted:Again, that doesn't mean it's good. this echoes my thoughts on make, with which i have done amazing and possibly torturous things
|
#
?
Jan 9, 2020 01:23
|
|
|
|
| # ? Apr 28, 2024 10:44 |
|
|
idea: distribute binaries
|
|
#
?
Jan 9, 2020 03:19
|
|
|
Bloody posted:idea: distribute binaries today: no problem, i'll maintain the binary distros. all i have to do is make sure the builds work, right? 6 months from now: his online handle was DaTroof. according to his friends, his suicide was sudden and unexpected
|
|
#
?
Jan 9, 2020 03:55
|
|
|
lets not op
|
|
#
?
Jan 9, 2020 06:40
|
|
|
Bloody posted:idea: distribute binaries if everyone just used windows 10 this would be easy
|
|
#
?
Jan 9, 2020 10:16
|
|
|
the theory behind the abomination that is webassembly
|
|
#
?
Jan 9, 2020 11:04
|
|
|
eschaton posted:the theory behind the abomination that is webassembly webarse is good actually
|
|
#
?
Jan 10, 2020 01:36
|
|
|
that implies there’s a real need to make web pages run code and that’s not true so you’re wrong
|
|
#
?
Jan 10, 2020 10:26
|
|
|
wasm + wasi will replace docker, you heard it here first
|
|
#
?
Jan 10, 2020 18:50
|
|
|
wabi-sabi? no, wasm-wasi.
|
|
#
?
Jan 10, 2020 18:51
|
|
|
wasm-wasoff
|
|
#
?
Jan 10, 2020 19:25
|
|
|
rotor posted:wasm + wasi will replace docker, you heard it here first iinvesting al my money in this ty
|
|
#
?
Jan 11, 2020 09:32
|
|
|
Gazpacho posted:i have never seen any other build tool that demanded more developer attention and babysitting than maven. even the build system developed for windows NT (a boatload of cmd scripts driven by nmake) managed to be more intuitive ive been begging you to post yoru pom.xml for years i want to see this heinous thing that tortures you
|
|
#
?
Jan 11, 2020 20:00
|
|
|
even if i had it it wouldn't be mine to post, and anyway we both know that your response would be "why are you doing the dumb things" while ignoring the answer I have always given, that the management mandated the use of maven while also imposing requirements (esp. variant builds) that conflict with maven's "opinions"
|
|
#
?
Jan 11, 2020 21:22
|
|
|
Gazpacho posted:even if i had it it wouldn't be mine to post, and anyway we both know that your response would be "why are you doing the dumb things" while ignoring the answer I have always given, that the management mandated the use of maven while also imposing requirements (esp. variant builds) that conflict with maven's "opinions" that is lovely, and also not maven’s fault
|
|
#
?
Jan 11, 2020 21:24
|
|
|
it is though, because the purpose of a build system is to do what it's told and maven can't be told what to do
|
|
#
?
Jan 11, 2020 21:26
|
|
|
the purpose of a build system is to build code the same way every time. if "your management" thinks they want randomized builds then that's idiotic and no build system would make that a design feature.
|
|
#
?
Jan 11, 2020 21:29
|
|
|
Gazpacho posted:even if i had it it wouldn't be mine to post, and anyway we both know that your response would be "why are you doing the dumb things" while ignoring the answer I have always given, that the management mandated the use of maven while also imposing requirements (esp. variant builds) that conflict with maven's "opinions" you have to admit, your situation is pretty funny hope you have taken the opportunity to go on a rant in the xml comments every time you have to fight maven
|
|
#
?
Jan 11, 2020 21:52
|
|
|
one particluar requirment for variant builds, was that entry points to an artifact had to be renamed on a per-customer basis as an additional obscurity measure on top of the underlying security solution. the customers wanted it, so they got it! the way this worked — put in place before I arrived, I think by our very "innovative" co-founder — was - each customer's renaming config was recorded in an XML file - the build server ran maven package to build the code from source (no tests, customers don't pay for tests you dummy) - at the end of that stage, maven executed antrun to call out to an external build.xml - the build.xml read in the renaming config and used xmltask to generate a custom target for the renaming and then executed it. then it zipped the artifacts into a distribution - next the build server ran maven again with um, the install goal? the package goal again with a different profile? i don't remember - that goal, whatever it was, executed a gmaven task, which is maven executing a groovy script - the groovy script did some other last-minute stuff that i don't remember but ant wasn't able to do, then it repeatedly ran maven deploy commands to push specific artifacts to the repository with different types and classifiers this was not the only variant-build requirement but it probably is the most entertaining story and the general theme of the whole process is having to graft things that are programmable onto maven because directly programming maven according to your business requirements is like pulling teeth e: oh i forgot to mention, at one point I added another big step and another subordinate tool to this process, while leaving all the others in place because deadlines, then fortunately i was able to beg my lead for a week to dive in and remove the xmltask stage Gazpacho fucked around with this message at 22:00 on Jan 11, 2020 |
|
#
?
Jan 11, 2020 21:56
|
|
|
thats interesting gazpacho i would have said "any kind of mutation of code you want to do at build-time needs to happen prior to invoking maven" but when i think about it, i bet they did this insane bullshit the way you describe in order to have one maven process on one build host spit out N artifacts (where N is the number of customers your compiling for) whereas i would have probably set it up such that N executors each produce one artifact
|
|
#
?
Jan 11, 2020 22:03
|
|
|
Gazpacho posted:it is though, because the purpose of a build system is to do what it's told and maven can't be told what to do
|
|
#
?
Jan 11, 2020 22:32
|
|
|
the purpose of a build system is to be better than rolling your own Frankenstein build process that’s probably going to be a bunch of shell scripts janitoring the file system, calling the compiler, etc. Some build systems, like maven, make the design decision to enforce a standard project layout and build pipeline, which is a perfectly valid choice
|
|
#
?
Jan 11, 2020 22:58
|
|
|
the closer your build tools are to imperative scripting, the further they are from righteousness
|
|
#
?
Jan 11, 2020 23:03
|
|
|
what maven does well: pulling libraries, fixing the top-level directory layout and especially a single top-level build output directory. this last one is such a small thing but it makes builds immensely more repeatable and despite this people at PrevCo would still fight against it
|
|
#
?
Jan 11, 2020 23:08
|
|
|
dads friend steve posted:the purpose of a build system is to be better than rolling your own Frankenstein build process that’s probably going to be a bunch of shell scripts janitoring the file system, calling the compiler, etc. Some build systems, like maven, make the design decision to enforce a standard project layout and build pipeline, which is a perfectly valid choice until you have business requirements that make invalid.
|
|
#
?
Jan 12, 2020 01:44
|
|
|
it sounds like cofounder had the right idea, of each customer build being exactly the same except for using a different renaming config. where they hosed up was trying to hack their bespoke build step in by loving around with antrun and rerunning maven and stuff instead of writing a plugin to rename entry points based on a config and then just using that plugin.
|
|
#
?
Jan 12, 2020 05:51
|
|
|
anyone used automation they *liked* to automatically merge approved pull requests in GH? i'd used bors a long time ago and the new generation (bors-ng) looks pretty great for automatically batching up lots of merge requests (i.e. you don't do it manually anymore), waiting for CI to mark your batched commits as good (on a staging branch), and then fast-forwarding master. so no more crazy logjam of 'urgh well i have to wait 20 minutes for CI to pass before I can merge this next PR, at which point master has changed and I have to update my branch and let it re-pass CI before I can even hit the merge button, and then do this for all of my other goddamn PRs'
|
|
#
?
Jan 14, 2020 18:27
|
|
|
I have no good answer to the question above, but I do have a question of my own: how is it that you have PRs all to the same repo and at such a frequency that you have that problem to begin with? Like how is that happening so often you need automation?
|
|
#
?
Jan 14, 2020 19:21
|
|
|
dads friend steve posted:I have no good answer to the question above, but I do have a question of my own: how is it that you have PRs all to the same repo and at such a frequency that you have that problem to begin with? Like how is that happening so often you need automation? I just want to say one word to you. Just one word. Are you listening? Agile!
|
|
#
?
Jan 14, 2020 19:26
|
|
|
mostly what crip said but ultimately it's that people work on feature/fix branches and our test suites take just long enough (they're not really That Long) that it requires more manual janitoring than it should on the part of engineers to actually get something in once it's been reviewed/approved; imo it's reasonable to want some automation around doing the actual integration outside of 'the tests passed the last time i ran them' ultimately it strikes me as pretty sane to batch that stuff up and test them on a staging branch anyway when you've already tested branches independently; i like that bors-ng is smart enough to bisect back on any failures to report whatever actually caused issues with integration. the smoothest shops i've ever worked at also batched up merges instead of every single (merge) commit getting its own release, but i could see lots of arguments depending on how you wanna do things
|
|
#
?
Jan 14, 2020 19:37
|
|
|
i am also a weirdo that kinda likes monorepos most of the time because the alternative is often even less manageable and leads to more confusion and anguish
|
|
#
?
Jan 14, 2020 19:38
|
|
|
yeah thats a pretty common issue with an active single repo codebase. You can ameliorate the problem somewhat by being really dilligent about isolating common code but it's always gonna be a thing.
|
|
#
?
Jan 14, 2020 19:53
|
|
|
totes, mostly i just want to remove the janitorial aspect of submitters having to talk amongst themselves to figure out when they can *actually* get merged long after the consensus is that it's fine and safe welp i'm gonna play with bors-ng and hope for the best; in the long-run, yeah, shortcuts to skip unnecessary tests for everything but F.I.N.A.L. M.E.R.G.E. sounds like the right direction to further reduce turnaround times
|
|
#
?
Jan 14, 2020 20:03
|
|
|
re: build servers, anybody used gitlab CI? that looks okay circleci is also fine, you can throw all your deps in a 10gb docker image and have nearly instant builds. it is an externally hosted service tho which is a cardinal sin. I'm currently using travis for my open sores rust stuff (lol) and that's okay too re: build systems, ant is terrible because procedural XML is terrible. gradle is worse though. one time I switched a project from ant to gradle because I was youthful and naive and afraid of XML and the only difference was that builds slowed down 10x. just use maven
|
|
#
?
Jan 14, 2020 20:52
|
|
|
this week im going to take the plunge and experiment with CDS https://ovh.github.io/cds
|
|
#
?
Jan 14, 2020 21:07
|
|
|
animist posted:just use maven request denied, bitch
|
|
#
?
Jan 14, 2020 21:13
|
|
|
the correct answer is azure devops.
|
|
#
?
Jan 14, 2020 21:26
|
|
|
animist posted:re: build servers, anybody used gitlab CI? that looks okay i have used it it's good for testing and building in docker containers, which makes it easy to get repeatable builds. but ironically, it's not so good at actually building docker images because in order to do a docker build in gitlab ci, you have to either run outside of docker (shell executor on some dedicated build host) or do docker-in-docker (disgusting, but it can be done) if you can stomach running docker builds in one kind of environment and everything else in a docker container, it works well. i actually suspect this exact same quandary is present in most CI systems that involve docker.
|
|
#
?
Jan 14, 2020 21:38
|
|
|
yup, most ci systems today seem to believe that docker is the beginning and the end of all things and it's a big reason i hate travis/circle/etc. jenkins: it's still fine, and the flexibility won't force you into hacky situations like the above
|
|
#
?
Jan 14, 2020 21:41
|
|
|
|
| # ? Apr 28, 2024 10:44 |
|
|
i've used a lot of jenkins instances, and no two are completely alike. there are lots of plugins to make it do exactly what you want. but they almost always become abandoned, and then you are stuck when you have to upgrade. gitlab ci has a much more limited feature set and no plugins afaik. but its very easy to keep up to date (if it actually meets your needs in the first place) so i recommend trying to make it work with gitlab ci if its already serving your git repos. jenkins is always there for you if you have some specific needs that aren't served by gitlab ci
|
|
#
?
Jan 14, 2020 22:01
|
|