|
CRIP EATIN BREAD posted:thats the one reason why i was interested in that CDS server because it does builds and deployments as a dependency graphs with gates that block the flow until something triggers it. this is absolutely what i want more of and i have yet to figure out a pleasant solution, but i can usually hack something together with jenkins and by that i mean i actually use jenkins-job-builder and make sure everything is under revision control. i feel like most jenkins hate, like so many things, is driven by using it in ways that are way too bespoke and unwieldy. like, maybe you don't need a zillion plugins for something that could be accomplished with a shell script that's actually testable and maintainable
|
#
¿
Jan 8, 2020 20:28
|
|
|
|
| # ¿ May 9, 2024 14:01 |
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
Bloody posted:docker is "works on my machine" taken to its logical conclusion
|
|
#
¿
Jan 15, 2020 02:21
|
|
|
MononcQc posted:you can do some really good layering and caching with docker, and it makes a huge difference if you have someone on your team who understands that poo poo vs. if you're just wiring garbage together like I would. lol more like you can do that and completely ignore reproducibility of builds and pretend that managing all the artifacts that go into an image don't matter so good luck deploying to production when one of the zillion services you depend on at build-time suddenly become deploy-time deps sorry i'm not yelling at you here i'm yelling into the clouds
|
|
#
¿
Jan 15, 2020 03:25
|
|
|
CRIP EATIN BREAD posted:using docker images from a hash instead of a tag to build your poo poo is so much nicer than any other mechanism true, and true with pretty much any dependency really not that many people do it  feels like every day I hear about a new outage due to floating deps
|
|
#
¿
Jan 15, 2020 17:09
|
|
|
totally, and ideally injecting actual values from that hash some other way fwiw i completely agree with the earlier take that vc-backed docker-the-company is not to be trusted, and personally i'd rather use any other container runtime at least the image format is standardized, and yeah, never don't be mirroring deps- including images- internally. i'm liking artifactory as a one-stop-shop for that kinda thing.
|
|
#
¿
Jan 15, 2020 20:16
|
|
|
|
| # ¿ May 9, 2024 14:01 |
|
|
Helianthus Annuus posted:at my old job, the NPM guys wanted to charge us 90k per year to run our own NPM mirror on-site lmao that explains why we just migrated from npm on-site to artifactory then
|
|
#
¿
Jan 16, 2020 00:24
|
|