• @dan@upvote.au
    link
    fedilink
    584 months ago

    At my workplace, we have a lint rule that reports an error if @nocommit is anywhere in the file, plus a commit hook that blocks all commits with @nocommit anywhere in them. It works well and has saved me a few times.

    Works pretty well, except the lint rule and its associated tests have to do something like "@no"+"commit" to avoid triggering it,

    • @bus_factor@lemmy.world
      link
      fedilink
      154 months ago

      I did the same thing with “DO NOT MERGE” back in the day. Saved some people who didn’t even know about the check.

    • @wim@lemmy.sdf.org
      link
      fedilink
      64 months ago

      In a lot of modern work flows this is incompatible with the development pattern.

      For example, at my job we have to roll a test release through CI that we then have to deploy to a test kubernetes cluster. You can’t even do that if the build is failing because of linting issues.

      • @dan@upvote.au
        link
        fedilink
        10
        edit-2
        4 months ago

        The test release shouldn’t have anything marked with @nocommit though… The idea is that you use it to mark code that is only temporary local debugging code that should never be committed.

        • @Bene7rddso@feddit.de
          link
          fedilink
          24 months ago

          Are you committing to master? I don’t see any reason why you shouldn’t commit your debugging code to your own branch. Obviously clean it up before merging

          • @dan@upvote.au
            link
            fedilink
            14 months ago

            My workplace uses feature flags rather than feature branches, and a continuous deployment cycle, so we only have one branch.