• dan@upvote.au
    link
    fedilink
    arrow-up
    58
    ·
    10 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
      arrow-up
      15
      ·
      10 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
      arrow-up
      7
      arrow-down
      1
      ·
      10 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
        arrow-up
        10
        ·
        edit-2
        10 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
          arrow-up
          2
          ·
          10 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
            arrow-up
            1
            ·
            10 months ago

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