Are you sure you have a `develop` branch on the gi...
# general
Are you sure you have a
branch on the git remote? Does it work with
./pants --changed-since=develop tailor
Does it work with
./pants --changed-since=main test tailor
(or whatever you name your main brach)?
so locally when I run this
./pants --changed-since=origin/develop tailor
there are no errors
local output from running above command
Can you expand the "Checkout" node in ci (and all sub nodes) and reveal that content? Can you just point us to the actual GH action yaml you use? Either would save alot of 20 questions / back forth.
github worflow
Copy code
name: Pants Unit Test

      - "*"
      - develop
  # Or when manually dispatched

    name: Perform CI Checks
    runs-on: ubuntu-latest
        python-version: [ 3.9.* ]
      - name: Checkout
        uses: actions/checkout@v3
          fetch-depth: 1
      - name: Bootstrap pants and manges 2-3 GHA caches
        uses: pantsbuild/actions/init-pants@v2
        # This action bootstraps pants and manages 2-3 GHA caches.
        # See: <|>
          pants-python-version: ${{ matrix.python-version }}
          # cache0 makes it easy to bust the cache if needed
          # just increase the integer to start with a fresh cache
          gha-cache-key: cache0-py${{ matrix.python-version }}
          # The Python backend uses named_caches for Pip/PEX state,
          # so it is appropriate to invalidate on lockfile changes.
          named-caches-hash: ${{ hashFiles('3rdparty/python/common.lock') }}
          # If you're not using a fine-grained remote caching service (see <>),
          # then you may also want to preserve the local Pants cache (lmdb_store). However this must invalidate for
          # changes to any file that can affect the build, so may not be practical in larger repos.
          # A remote cache service integrates with Pants's fine-grained invalidation and avoids these problems.
          #          cache-lmdb-store: 'true'  # defaults to 'false'
          # Note that named_caches and lmdb_store falls back to partial restore keys which
          # may give a useful partial result that will save time over completely clean state,
          # but will cause the cache entry to grow without bound over time.
          # See <> for tips on how to periodically clean it up.
          # Alternatively you change gha-cache-key to ignore old caches.

      - name: Setup Python ${{ matrix.python-version }}
        uses: actions/setup-python@v4
          python-version: ${{ matrix.python-version }}

      - name: Check BUILD files
        run: |
          ./pants --changed-since=origin/develop tailor 
          ./pants --changed-since=origin/develop update-build-files
      - name: Lint
        run: |
          ./pants lint ::
      - name: Test Everything
        run: |
          ./pants test ::
could it be because main branch doesn't have pants on it yet?
main branch - no pants (no,, BUILD ), pants is being introduced on a feature branch and would get merged in
So ... why did you pick
fetch-depth: 1
? That's clearly the problem.
If there was no particular reason you picked that, you want
fetch-depth: 0
to start with: That will get you all history, which is slowest, but also ensures all commit ranges will be present. Since you are asking for a commit range with --changed-since, a fetch depth of 1 is always the incorrect answer. It must be 2 or greater. Picking a number though is also fraught with peril, you may pick 10 which is usually enough, but sometimes not. Those sometimes failures will likely be confusing; so picking 0 is safe.
so is it just hte range of how many refs it check that is the issue
This may or may not solve your problem, as others have pointed out you need your branch to be present on origin, but its a baseline fix you need.
is the convention to use 0 or greater than 2 when checking for changed-since with pants
so is it just hte range of how many refs it check that is the issue
I think so, yes.
so our main branch is called dvelop
@abundant-analyst-12845 this is not a Pants thing at all. In general - pants aside, to do history calculations with git you must fetch more than 1 commit.
ah ok thanks
1 commit is the present. History requires looking at more than 1
@abundant-analyst-12845 fwiw, this is exactly what Nathan was pointing out with "If it's a shallow clone or similar" in - a fetch depth of 1 is the shallowest possible clone.
🙌🏿 1
thank you so much for the clarity