• @[email protected]
    link
    fedilink
    589 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
      link
      159 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.

    • @[email protected]
      link
      fedilink
      69 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.

      • @[email protected]
        link
        fedilink
        10
        edit-2
        9 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.

        • @[email protected]
          link
          fedilink
          29 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

          • @[email protected]
            link
            fedilink
            19 months ago

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