• wim@lemmy.sdf.org
    link
    fedilink
    arrow-up
    7
    arrow-down
    1
    ·
    8 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
      8 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
        ·
        8 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
          ·
          8 months ago

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