Honestly, I wouldn’t be surprised if the inclusion of some small AI feature is what justified the rest of this work being done. As in, someone got approval for tab groups only because they were smart enough to describe it as “AI powered tab groups“. Just speculation

OP, my personal preference is to supply raw k8s manifests in a project. These are far easier to manipulate using tool called kustomize. Just think of it as an alternative to helm. The big thing is that kustomize removes the need for forks because it can run against manifests defined by a url.

It looks safe to me in the sense that I don’t see any malicious code in here. I don’t think the committee is trying to sneak in security hopes or similar. So all good on from that perspective.

It’s a very simple helm chart which is consideration! Here’s the thing with charts. They’re meant to be an official means of distributing your app’s manifests for k8s. One package with all runtime needs defined. If the chart supports every tweak I need, then it’s great! If it doesn’t, then I need to modify it myself. This usually means forking the project, making edits, and templating from the fork. It’s a lot of overhead for end users. If the maintainer is willing, it’s so much easier to create an issue or submit a PR with the needed changes.

Your project has some stars and forks. People are likely using it. Grats! The helm chart doesn’t like meet everyone’s needs and I would expect this to spur some extra issues and PRs. Is that good or bad? That’s up to you!!

There’s cryptpad though I don’t have a clue how complicated it is to manage. But it’s a decent user experience.

I had to look up the releases for this one 😂. It must have been v1. I last used flux maybe 2+ years ago. That predates flux v2.

Have you used v2? If so, what do you think about it?

Oh I could easily be wrong about forgo having integrated ci/cd already. It’s the only tool I mentioned shove that I have never used before. I’m not a good source on this one.

But I have used both flux and argo quite a lot. I’ll admit that it flux implementation was bad, but it was just a bad experience for everyone using it with me. It was a memory hog and often created. Very few people understood how to use it correctly. When there were errors with e.g. a helm template, you just had to go looking for issues and read through the log. It moved git tags around so you don’t get a history of what flux was doing. I could probably remember more issues if I tried.

But none of that was a problem with Argo. We just started using it successfully on day 1. Plus its UI is fantastic and a huge advantage. It’s easy to navigate, spot issues, troubleshoot, etc. It also exposes users to resources they unknowingly create because Argo displays owned resources. This part really helped people understand what was going on in k8s. Oh and argo is very extensible. Maybe flux is too but I haven’t tried.

They’re both good and quite similar on the surface. But I find that larger, more complicated uses tend to get messy with gitlab because of the heavy use of bash. However, actions are (always?) written in typescript. If your automation needs a lot of logic to handle varying uses, then it’s nice to avoid bash and code with a more language.

In other words, I’ve seen a few monstrosities that large companies build into gitlab and yikes!

Nope. I’m using a mobile app (voyager). No browsing history available

I would have liked to but I can’t access the deleted post now. Does Lemmy provide a means of seeing deleted posts?

If you’d like to learn more about Haptic, why it’s being built, what its goals are and how it differs from all the other markdown editors out there, you can read more about it here.

As others have noted, the app doesn’t work on mobile yet. Anybody willing to share the content here for mobile users?

That basic idea is roughly how compression works in general. Think zip, tar, etc. files. Identify snippets of highly used byte sequences and create a “map of where each sequence is used. These methods work great on simple types of data like text files where there’s a lot of repetition. Photos have a lot more randomness and tend not to compress as well. At least not so simply.

You could apply the same methods to multiple image files but I think you’ll run into the same challenge. They won’t compress very well. So you’d have to come up with a more nuanced strategy. It’s a fascinating idea that’s worth exploring. But you’re definitely in the realm of advanced algorithms, file formats, and storage devices.

That’s apparently my long response for “the other responses are right”

The configuration is often committed to the repo. And some repos heavily rely on the precommit actions running before you can push or have pipelines function correctly

100%

I know a guy that considers git pre-commit hooks a form of code injection and thus a security risk. So he disables them on repos he works with. And to be fair, it’s absolutely a viable vector for attacking developer machines. I think a tasks.json fits into that exact same bucket.

These kinds of automations are suuuper useful and I do like to use them. But also review a code base before cloning!

Interesting. When I first viewed this post, there were 3 downvotes and only 2 upvotes. Is this not the type of content that people want to see here?

I’ll check back again later and see if/how those numbers change.

Never do this.

Git is all about tracking changes over time which is meaningless with binary files. They are bloat for your repo, slowing down operations. Depending on the repo, they are likely to change from CI with every commit. That last one means that every commit turns into 2 commits btw. They are can ruin diffs. I could go on for a long time here.

There are basically 0 upsides. Use an artifact repository instead!

My pleasure. Thanks for posting! And feel free to ask more questions as you tackle this one.

I’m on my phone so I can’t really test these out. But this should give you a few methods for printing the list of files changed.

Here’s a similar page to show the changes for a specific file. I expect that git blame will be similarly useful.

A few others that may help you get started as well:

git —help
git rev-parse
git log
git history

Yikes! Is this a one-time task?

Well this is definitely a bit odd. Send like those comments should be included with the original change. Or maybe they shouldn’t be recorded as comments at all and they should be a git commit message. And where does that hard copy report come from? Anyways, back to your actual question.

At this point, I’m still suggesting a tiny utility to assist with adding the comments. It looks like %ATTCHANGE and %REM are part of a very sort list of possible values. If so, a little cli tool can definitely help there. It could also handle the general comment structure and the changed value easily. Do these comments ever include something besides #ACCEPTED?

The tricky part is the ‘12.24/4’. It sounds like you go through the report and then find the files/lines to create these comments. Is that right? It would be tricky to code a cli tool for doing that because you need to jump around between files.

Last note for now, some simple git commands can definitely help you here. You could easily generate a list of changed files and lines. Another could show you the changed text. For any given change. Etc.

Can you give an example of the change and your comment for a single file?

2000 is a lot of files. If you need to do this often, it might be best to build a small cli tool to make this easier or fully automated. It really depends on how you choose to create those comments.