Can someone help me deal with bitbucket and build:affected

[mattiLeBlanc]

Hi,

I started using build:Affected in my bitbucket pipeline to cut down on build and deployment time to AWS, but I am getting this error in bitbucket:

+ pnpm run build:affected
> @apollo/source@0.0.0 build:affected /opt/atlassian/pipelines/agent/build
> nx affected --target build --base=origin/master~1
fatal: ambiguous argument 'origin/master~1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
nx affected

I am pretty new to NX and I am not sure why this is happening.
I assume something with NX not having any git history in the container running the deployment.
So is it actually possible to achieve build and deploy affected?

My deploy command looks like:

 - step: &deploy
        name: build
        size: 2x #doubling memory size
        image: node:18.14.2
        caches:
          - node
        script:
          - echo "deploy to $ENV"
          - npm install -g pnpm
          - pnpm install
          - pnpm run aws-config
          - pnpm run reset
          # - pnpm run build
          - pnpm run build:affected
          - pnpm run bootstrap
          - pnpm run deploy:affected
          # - pnpm run deploy
          - pnpm run migrate
        artifacts:
          - cdk.out/**

One thing that is causing the issue I think is that I deploy based on a tag to trigger the deployment to staging and production:

  tags:
    '*':
      - step:
          name: None
          script:
            - npm version
      - step:
          <<: *deploy
          name: Deploy to "staging"
          deployment: staging
          trigger: manual
      - step:
          <<: *deploy
          name: Deploy to "production"
          deployment: production
          trigger: manual

Because I saw that the Master deployment (going to Development) was working as expected.
Just the tag deployment is failing:

I just found this in my npm package file, setup by my coworker who is no longer working for us

    "build:affected": "nx affected --target build --base=origin/master~1",
    "deploy:affected": "nx affected --target deploy --base=origin/master~1",

I am not sure why he is using master~1 because that doesn't work for tags, but works for a master deployment.

When I Look at the master deployment via bitbucket, I see this in the first step:

+ umask 000
+ GIT_LFS_SKIP_SMUDGE=1 retry 6 git clone --branch="master" --depth 50 https://x-token-auth:$REPOSITORY_OAUTH_ACCESS_TOKEN@bitbucket.org/$BITBUCKET_REPO_FULL_NAME.git $BUILD_DIR
Cloning into '/opt/atlassian/pipelines/agent/build'...
+ git reset --hard 88f3715496a3f94d80315e8bddfc6b64cab6dbda
HEAD is now at 88f3715 update deployment strategy
+ git config [user.name](http://user.name/) bitbucket-pipelines
+ git config user.email commits-noreply@bitbucket.org
+ git config push.default current
+ git config http.${BITBUCKET_GIT_HTTP_ORIGIN}.proxy http://localhost:29418/
+ git remote set-url origin http://bitbucket.org/$BITBUCKET_REPO_FULL_NAME
+ git reflog expire --expire=all --all
+ echo ".bitbucket/pipelines/generated" >> .git/info/exclude
+ chmod 777 $BUILD_DIR`

which is a tagged commit, but this will use the master step for the pipeline:

 branches:
    master:
      - step:
          <<: *deploy
          deployment: development
          name: Build and deploy to development

and that works fine but when I use the tag deployment bit it fails with the error I mentioned at the beginning.

+ umask 000
+ GIT_LFS_SKIP_SMUDGE=1 retry 6 git clone --branch="v0.6.1" --depth 50 https://x-token-auth:$REPOSITORY_OAUTH_ACCESS_TOKEN@bitbucket.org/$BITBUCKET_REPO_FULL_NAME.git $BUILD_DIR
Cloning into '/opt/atlassian/pipelines/agent/build'...
Note: switching to '88f3715496a3f94d80315e8bddfc6b64cab6dbda'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
  git switch -c <new-branch-name>
Or undo this operation with:
  git switch -

I am then running in detached head state....which makes sense because a tag is pointing to a commmit.
Does it mean I have to use a release branch with a tag?

[jaysoo]

The git ref is not available, probably due to the cloning strategy that's being used in Bitbucket.

You may need to change the strategy, or some steps to ensure that the branch/tag you are using as --base is available. For PRs, you should compare to the main/master branch, and for merges into main/master, it should be the last successful SHA (if Bitbucket provides this info) or HEAD^.

[mattiLeBlanc]

@jaysoo Are there any good docs on this or examples I can follow?

[mattiLeBlanc]

@jaysoo I have got affected working but not it is not completely useful due to the CI/CD strategy I use.
I create branches for features and when work is done and PR approved, those branches are merged into master.
But I don't deploy to Staging and Production immediately.
I may collect a couple of merges and then at one point tag a commit with a version and that triggers a Bitbucket deployment pipeline that will deploy to Staging and when production (manual trigger).

This is a method I used before I started utilizing NX.

The problem I seem to have is it only compares the tagged commit against master, but the commit is part of master. So it look like it only comparing this current commit with the previous one.

But let's say we have the following commits:
Commit 6 Tagged v1.1.0 -> deployed to AWS via bitbucket
Commit 5
Commit 4
Commit 3
Commit 2
Commit 1 Tagged v1.0.0 -> deployed to AWS via bitbucket
Commit 0
....

It seems to not detect changes happening in commit 2-4, unless they last commit has changes in the same projects, then it will trigger a build.

I have a shallow understanding of Git, enough to work with Repos and branches etc and I am new at NX.
Should I move away from this tagging release strategy or is is possible to make this work, so it recognises Commit 1 was last deployed and now it needs to look at changes after 1? I don't think that is possible.
Maybe I can find the head of the latest tag before this, because that should show the change between Commit 1 and Commit 6

I am not sure I want to be working with release branch to get a good diff between master and release branch. Because that means slower release of features, unless I create a release branch for each filter.

I hope you can point me in the right direction.