• 9 Posts
  • 138 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle

  • 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!







  • A complicated plugin ecosystem (e.g. Jenkins) makes for a terrible use experience. It’s annoying to configure a bunch of config files. Managing dependencies can be a complete nightmare. these problems also complicate your ci/cd.

    So I’ll offer a slightly different answer. I prefer a single file instead of splitting up the config. And I’ll use OpenTelemetry as an excellent example of why. the plugins are compiled right into the app binary. This offers a ton of advantages, including a great reason to merge all of your app configs in a single file.

    This really only works well if you have a good app though.








  • So I read a bit of Mozilla’s documentation about this feature. It sounds like they’re trying to replace the current practices with something safer. Honestly, my first thought is that this is a good thing for two reasons.

    • It’s an attempt to replace cross site tracking methods, which are terrible
    • Those of us that fight against ads, tracking, etc. can simple use typical methods to block the api. Methods that were already using (I think)

    If both of these are true, then it could be a net positive for the world. Please tell me if I’m wrong!





  • 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.