|
SVN itself has no sort of code review functionality, but there's plenty of code review tools that can be used with SVN.
|
#
¿
Jun 3, 2015 00:52
|
|
|
|
| # ¿ May 4, 2024 10:09 |
|
|
Dren posted:So far GoCD seems like it has some niceties that Jenkins lacks. It puts the idea of a pipeline build where artifacts are published between pipeline stages right up front. Potentially solving the issue of building tagged releases, it has the ability to kick off an entire pipeline from a specific commit hash. It also puts all config into a single XML file that can be backed up and shared which is much easier to deal with than whatever Jenkins does (last I looked config was split across lots of directories). One thing that's a blessing/curse is GoCD won't support a multi-line script right in a task the way that Jenkins does. I shouldn't complain, I've said for years that keeping huge build scripts in Jenkins and outside of source control is a bad thing, but being restricted to not scripting in there at all feels like tough love. FWIW this is all trivially doable with Jenkins (to the extent that anything involving Jenkins can be said to be trivial), but I can definitely see the value in a tool that actually points you in the right direction rather than basically requiring a knowledgeable consultant to end up with anything remotely sane.
|
|
#
¿
Jun 4, 2015 18:03
|
|
|
okay? that's sort of a non-sequitor
|
|
#
¿
Jun 4, 2015 20:50
|
|
|
Dren posted:I understand and I've done this sort of thing in Jenkins before. The end result with Jenkins was sort of complex and opaque. There's something to be said for the way GoCD presents a pipeline flow showing you everything upstream and downstream of a pipeline stage. Having a visualization of your complicated build be a key part of the app is really nice. To be fair, maybe that's available in Jenkins and I have
|
|
#
¿
Jun 5, 2015 17:44
|
|
|
Our repos that non-developers touched regularly (mostly website stuff) are set up to only allow pushing to master by merging a PR that has passed tests, mostly because it helps catch mistakes from users who don't know how to use version control and shouldn't need to learn anything more than the absolute basics. With a large number of developers working on a repo you really want a merge queue, but I've always seen gated merges without a merge queue as a lovely attempt at solving a social problem with technology.
|
|
#
¿
Mar 31, 2017 21:55
|
|
|
At the minimum you need to rerun the tests after making changes requested during review, and the final review pass shouldn't take a significant amount of time.
|
|
#
¿
Apr 3, 2017 01:50
|
|
|
We store things as jenkins artifacts and use the copy artifact plugin and it's awful and a common source of spurious build failures.
|
|
#
¿
May 4, 2017 23:50
|
|
|
The more I use Jenkins the more I am convinced that if you can do something with a shell script rather than the Jenkins plugin built specifically for that task, you should.
|
|
#
¿
Jul 28, 2017 01:30
|
|
|
There's two major components to Blue Ocean: the use of the in-repo Jenkinsfile to configure things, and the pretty new UI. Jenkinsfiles are an improvement, but don't really solve any of the actual problems I have with Jenkins. You can't run a Jenkinsfile locally, so the fact that you can put logic in them is just as much of a trap as it always has been. Jobs which were working yesterday will still break tomorrow because someone updated a plugin that you aren't even using. The new UI is a broken pile of garbage. It looks better than the old UI, but is incredibly slow and buggy.
|
|
#
¿
Jul 28, 2017 18:13
|
|
|
The solution to most problems involving Jenkins plugins is to stop using plugins for anything that doesn't inherently require a Jenkins plugin.
|
|
#
¿
Sep 25, 2017 19:29
|
|
|
Do not use a Jenkins plugin for anything other than integrating with Jenkins itself.
|
|
#
¿
Jan 17, 2018 02:51
|
|
|
We have one person in charge of ensuring Jenkins itself is in a working state, and all the jobs are managed by the individual teams that need them. It's never been an issue. As long as you don't install plugins and give all your jobs appropriate tags for what nodes they can run on there's nothing that can really conflict between teams.
|
|
#
¿
May 9, 2018 21:01
|
|
|
Internet Explorer posted:Doesn't AWS do gaming stuff with Lumberyard? Kind of odd for them not to support UDP load balancing. Star Citizen is the only game of note using Lumberyard, and it's not really notable for the right reasons.
|
|
#
¿
May 26, 2018 16:49
|
|
|
Helianthus Annuus posted:Now you gotta put a bunch of sketchy plugins on there, and try to guess which ones will never be updated ever again. That's easy. All of them.
|
|
#
¿
Jun 24, 2018 03:23
|
|
|
Never install a Jenkins plugin unless it is a hard requirement for what you are trying to do. And even then give a serious consideration to an absurd rube goldberg machine involving a webserver written in bash first.
|
|
#
¿
Jun 24, 2018 05:22
|
|
|
Blue Ocean's pipeline overview display is kinda nice as long as you don't have more than like 10 jobs at any given step of a pipeline. Actually inspecting what happened in a given pipeline step is an utter disaster, though.
|
|
#
¿
Sep 19, 2018 22:00
|
|
|
lld now works well enough on windows for Chrome and is pretty dramatically faster than microsoft's linker, so it may be worth looking into using that.
|
|
#
¿
Nov 14, 2018 19:48
|
|
|
Docker the company isn't dead. They sold off the failed enterprise products then raised another round of funding and pivoted into building developer tools for container stuff.
|
|
#
¿
Mar 13, 2021 05:14
|
|
|
The biggest problem with the "throw it over the wall" approach is the one-way flow, not the fact that there's some division of labor. I don't have any clue how the server-side stuff I sometimes touch is actually deployed, but that doesn't mean I just do whatever I feel like and make them deal with it. It's the exact opposite, in fact. They tell me what they need for the prod setup and I build that.
|
|
#
¿
Mar 28, 2021 01:27
|
|
|
Blinkz0rz posted:We've had good luck with a continuous cost savings project that goes through every dev team's infra and figures out what's over provisioned or needs some extra attention and lets the team prioritize accordingly. It's helped dramatically in lowering costs as well as aligning with dev on a shared goal of making their work more cost conscious. I really have no idea why you think that having devs make infra decisions is necessary or even useful for that. I’ve had ops come to me and say “hey we’re spending a fuckload on high durability storage for this thing you wrote”. We had a short meeting about it, came up with a feature that let us store most of the data in a cheaper way, and shipped it. At some point I’m sure they told me the names of the different storage types and why there was a big price difference, but it would have been a pretty stupid waste of time for me to go learn everything I needed to know to pick the appropriate ways to store things rather than just trusting my colleague who specializes in that.
|
|
#
¿
Mar 29, 2021 02:21
|
|
|
You are allowed to put quotes around your strings in yaml, you know. Just because it lets you do stupid things doesn't mean you have to.
|
|
#
¿
Apr 10, 2021 03:39
|
|
|
A makefile is basically just a shell script that hopefully supports incremental rebuilds, and that’s not really a good thing in most circumstances.
|
|
#
¿
Sep 18, 2021 17:41
|
|
|
Nomad's competitive advantage over k8s is that it's a bit easier to get started with, and that's about it. I hope it is obvious why this isn't a good reason to introduce it when you're already using k8s.
|
|
#
¿
Feb 18, 2022 04:28
|
|
|
I would not recommend doing that unless you have very modest requirements. Github actions is not very good at keeping their macOS builders up to date (e.g. they still haven't updated to macOS 12 and so can't run Xcode 13.3) and even on the Enterprise plan it took us ~6 months to successfully get bumped up 50 concurrent macOS jobs.
|
|
#
¿
Mar 21, 2022 02:52
|
|
|
It is very frustrating that there are still not any good options for hosted macOS CI. GHA's macOS builders are awful. CircleCI has much better macOS support but their core CI product is bad. Travis was good for a while but they died. Gitlab's is still in private beta. Xcode Cloud was designed to look good in a WWDC presentation rather than to be a usable product. Everything else that I'm aware of requires that you host your own builders, which is a gigantic headache.
|
|
#
¿
May 5, 2022 20:39
|
|
|
Github Actions uses the same build agents as Azure DevOps. Probably less incompetent sales than paying for them via Github, but they have the same problem of that there's seemingly one person maintaining macOS support as a side project and so it takes an entire year to add support for new macOS versions.
|
|
#
¿
May 5, 2022 21:00
|
|
|
The agent software is not what I was referring to or the problem with GHA on macOS. It is the machines and the software they have installed on those machines.
|
|
#
¿
May 8, 2022 04:24
|
|
|
The next step is for it to magically stop working and then never work again.
|
|
#
¿
Aug 24, 2022 21:17
|
|
|
Methanar posted:It's some seriously jacked up PKI where x509 client certs which belong to an expired CA are somehow still working. If you touch it then it's your problem to fix when it stops working, so I highly recommend not touching it.
|
|
#
¿
Aug 25, 2022 04:22
|
|
|
Yeah, I've found producing tags as part of a release to work better than producing releases from tags. Creating the git tag is part of publishing a release, so it should come after you build the thing which will be published.
|
|
#
¿
Nov 7, 2022 22:26
|
|
|
Ours lets you skip slides but because it's forty different 30 second videos I've found it's less distracting to just leave it playing (muted) on a second monitor and occasionally hitting next than to actually bother skipping through it.
|
|
#
¿
Mar 10, 2023 21:25
|
|
|
Hashicorp is just the latest company to discover that the red hat model has not worked for a single company other than red hat. If you're using a large open source project that's being developed as the primary focus of a company then you should probably assume that it will eventually become not open source.
|
|
#
¿
Aug 17, 2023 17:29
|
|
|
|
| # ¿ May 4, 2024 10:09 |
|
|
xzzy posted:The red hat model doesn't even work for redhat, that's why they're killing off free access to RHEL rpm source. I am generally not a fan of calling a big exit a “success”, but I think $38 billion is big enough to count regardless of what happens afterwards.
|
|
#
¿
Aug 18, 2023 00:14
|
|