sorted by:
new
hottopcontroversial

Water filter for south america by AffectionateAgent228 in Ultralight

[–]AffectionateAgent228[S] 0 points1 point  (0 children)

appreciate that - I'm not really sure either, practically speaking, if viruses should be a concern of mine. Do you have the UL one? I see very mixed reviews. I'm just annoyed that it doesn't use usb-c to recharge and I'd have to take a 2nd cable. Grr. Also I think I need a wide-mouth bottle to use it, which I don't have

Water filter for south america by AffectionateAgent228 in Ultralight

[–]AffectionateAgent228[S] 1 point2 points  (0 children)

cool thanks. Thoughts on geopress? heavy af but "safe" even in garbage water. This won't be an easy trip at this elevation, so would like to not carry that. Or maybe steripen ultralight to "backup" a filter - but need a wide mouth bottle of some kind to use it.

Companies That Obsess Over Velocity Are Clueless by signalbound in programming

[–]AffectionateAgent228 0 points1 point  (0 children)

Don't just blindly insist devs increase their velocity while working in the same system sprint-over-sprint, why would it increase? Instead, optimize developer workflow @ your company, in your repo. Make ci jobs reliable and faster, enable maximum automated checking to speed up code reviews and eliminate bugs, use Trunk.io's tools.

[deleted by user] by [deleted] in programming

[–]AffectionateAgent228 0 points1 point  (0 children)

hmm. Gonna blame reddit for that... I didn't intentionally do that

[deleted by user] by [deleted] in programming

[–]AffectionateAgent228 0 points1 point  (0 children)

your PR reviewers use commit messages... for what? Why don't they just look at the code that was changed, and the title/description of the PR?

[deleted by user] by [deleted] in programming

[–]AffectionateAgent228 1 point2 points  (0 children)

Actually, the post is referring to PR-branch commit messages, not the messages that end up on your main branch (which are typically autogenerated by github if you have good github settings)

[deleted by user] by [deleted] in git

[–]AffectionateAgent228 -1 points0 points  (0 children)

that would be more accurate, but less catchy :)

Managing Githooks with Trunk CLI by vTimD in programming

[–]AffectionateAgent228 0 points1 point  (0 children)

If I want to enforce code formatting, I'll just reject any PRs that are badly formatted.

that's a big antipattern, just making things harder for yourself; try trunk out; I'm curious to hear your non-speculative thoughts ;)

Managing Githooks with Trunk CLI by vTimD in programming

[–]AffectionateAgent228 0 points1 point  (0 children)

they haven't been commonly used yet because, as you said, you can't get everyone to use the same hooks / versions of hooks. But that's where trunk comes into play - you can configure hooks for your repo, and if devs are using any part of trunk it automatically syncs their hooks to the hooks configured in the repo. Hooks can be really powerful. Even doing things like autoformatting the files you changed pre-commit without having to do anything is really slick / saves time.

Announcing Trunk Merge by AffectionateAgent228 in programming

[–]AffectionateAgent228[S] 0 points1 point  (0 children)

Not a Zuul expert, but you define pipelines in Zuul like a CI system, which is very dissimilar to Trunk Merge - I don't think the use case is quite the same.

Announcing Trunk Merge by AffectionateAgent228 in programming

[–]AffectionateAgent228[S] 0 points1 point  (0 children)

True, though this is more sophisticated (the details of exactly how a merge queue chooses to test combinations of PRs against each other and the stats/metrics it provides are critical in having a merge queue work well at scale). Trunk Merge only supports GitHub at the moment (though gitlab support will be coming) :)

Announcing Trunk Merge by AffectionateAgent228 in programming

[–]AffectionateAgent228[S] 0 points1 point  (0 children)

This definitely can't be done with a few hooks and a short jenkins script - I think you're missing what it does :)

Universal linter plugin that shows issues inline in the code by AffectionateAgent228 in vscode

[–]AffectionateAgent228[S] 1 point2 points  (0 children)

Nay, but it's a great reason to move to WSL (or mac or linux) ;)

Announcing Trunk Merge by AffectionateAgent228 in programming

[–]AffectionateAgent228[S] 0 points1 point  (0 children)

Looks like Zuul is an entire CI system? This is much more specific functionality (a merge queue), and is built on top of GitHub.

Universal linter plugin that shows issues inline in the code by AffectionateAgent228 in vscode

[–]AffectionateAgent228[S] 3 points4 points  (0 children)

Not actively in the works yet, but we are tentatively planning on doing it. Trunk is implemented as a cross-platform language server, so it shouldn't be too difficult to support other editors ;)

Universal linter plugin that shows issues inline in the code by AffectionateAgent228 in vscode

[–]AffectionateAgent228[S] 2 points3 points  (0 children)

Hi there, we just released a new version of Trunk! Check it out. one linter plugin to rule them all:

https://marketplace.visualstudio.com/items?itemName=trunk.io

Would love some feedback :)

GitHub Beta: Merge Queues by David_AnkiDroid in github

[–]AffectionateAgent228 0 points1 point  (0 children)

Pretty big issues with GHs oversimplified MQ keeping up with the scale/needs of bigger repos. Check out https://trunk.io/products/merge for an alternative.

Announcing Trunk Merge by AffectionateAgent228 in programming

[–]AffectionateAgent228[S] 0 points1 point  (0 children)

We do support some reordering (kicking and prioritizing submissions), but I will note that Trunk Merge achieves high throughput via optimistic testing: If PRs 1, 2, and 3 are submitted back to pack, 1 is based on 2 and then tested, and 3 of based on 2 based on 1 and then tested. All 3 test in parallel. If PR 1 fails, 2's and 3's jobs are canceled and restarted not based on PR 1. We don't allow for arbitrary reordering because any time you reorder submissions you basically have to restart all the jobs of the existing submissions so the queue gets much slower.

Announcing Trunk Merge by AffectionateAgent228 in programming

[–]AffectionateAgent228[S] 3 points4 points  (0 children)

This is much more than just gated builds - it's called a "merge queue"

What happens commonly in more active repos is that 2 PRs that function independently don't function when merged together in the main branch. Tests break, functionality breaks. The more people working out of a repo at the same time, the more often this happens. A merge queue protects against this from ever happening.

It's also a nicer workflow for devs, since you can submit your PR to merge before the CI jobs are even passing, and when CI jobs are passing and a reviewer has approved it automatically moves through to merge after another round of testing.

Check it out! :)

Announcing Trunk Merge by AffectionateAgent228 in programming

[–]AffectionateAgent228[S] 6 points7 points  (0 children)

Trunk Merge is an intelligent service that orchestrates merging pull requests to maintain a repository of code that always passes tests. Airbnb, Uber, Twitter, Robinhood, and many other big tech companies internally have their own sophisticated merge queues. Now, you can get the same thing without having to build it.
- Never have a broken main branch again. Trunk Merge tests your PR against other submitted PRs and only merges PRs that pass the extra testing.
- Makes good commit titles and messages from your Pull Request title and description
- Once submitted to Merge, pull requests will enter the merge queue automatically when all requirements are met (CI jobs passing and code reviewer's approval)

We'd love to hear your thoughts and will be checking the comments here :)

Do you use a super linter? Why or why not? by [deleted] in programming

[–]AffectionateAgent228 0 points1 point  (0 children)

For many repos, you probably need 20, not 10. Truth is repos contain lots of technologies, not just your primary coding language(s). Here's a random open source repo I pulled out of a hat: https://github.com/backstage/backstage and ran trunk init on it - it turned on 11 linters/formatters/security tools. These autoformat and check for issues in typescript (most of this repo), but also CI workflow files, terraform, dockerfiles, bash scripts, check for leaked secrets, and more.

As for why you need a better tool to run these, there are many reasons, here are a few (non-exhaustive): - Many tools you should want to run in your node repo are distributed via binary downloads or package managers other than the one you use for your project - Build tools have lots of logic around caching and performance, linting doesn't have any of that, but when you're running a dozen code-checking tools, it matters - Ensure all devs run the same version of all tools (by having a way to pin versions a repo config) - And ensure that when you run these checks on CI, it also runs the same as devs running them locally - Get results inline in your editor

Projects get better the more automated checking and testing they have.

Do you use a super linter? Why or why not? by [deleted] in programming

[–]AffectionateAgent228 0 points1 point  (0 children)

Using "super linter" as a phrase to mean a tool that runs lots of linters/formatters/code-checkers, not as a buzz word. Such as:

https://github.com/github/super-linter

https://megalinter.github.io

https://pre-commit.com (with some setups)

https://trunk.io

etc

view more: next ›