Tag trigger selects main/master branch and not the branch related to the tag

Description of the issue

I’ve setup a build trigger on a tag starting with v*, when I create the tag on github and link it to a specific branch the trigger starts correctly, however the main branch is pulled, and not that related to the tag.
The git clone step version I’m using is the 6.2.1, the variable (unmodifiable) of the git branch to clone is $BITRISE_GIT_BRANCH which should be set by default, as for the other triggers, with the branch related to the trigger.

Environment

Which build Step causes the issue and which version of the step?

E.g.: Git Clone v6.2.1

Reproducibility

  • Setup a trigger on git tag using v* as a regexp
  • Create a tag on github by adding a release, link the tag to whichever branch (in my case, to the branch “release-v36”
  • The trigger starts cloning branch “main” and not branch “release-36”

Hey!
release-v36 does not seem to match the v* pattern. Considering it’s cloning main, I’d guess a different trigger is executed. Can you check what other triggers you have? Have you tried setting the regular expression to *v*?

Hi! Thanks for your answer, I wouldn’t know how could a *v*help me though.

Just to be clear on our trigger setup:

  • bugfix-* | hotfix-* | feat-* regexps filter branch name on push and trigger a dev build, works just fine.
  • main branch pushes trigger an internal build, works fine as well
  • release-* regex filters branch name on pushes and triggers a staging build (our open beta), works fine

Now, we added a trigger on tags (so not on pushes), with regex v*that should trigger a production build (the actual build we send to the stores). The trigger reacts correctly to the tag, when I go on github and create a release by tagging a specific branch and using, for instancem, v36 as the tag name, bitrise reacts to the tag and starts correctly the production build, however, the branch it cones is not the branch I associated to the tag, but the master/main branch of our repo. I’m afraid that, if we tag to some commit before the current last commit of main/master, bitrise will pull the latest version of main and eventually unwanted new commits.

1 Like

Having almost exact same issue. We want to push tags from release/ branch but the build is taking master as the branch.
Not sure also why the manual trigger modal in the web ui in the advance tab have the option to define the branch and the tag if bitrise only take master as the branch when using a tag in the trigger map. I really hope this can be changed as is AFIAK normal gitflow.

Thank you for the additional details. I think I managed to reproduce a behavior that you described. However, it looks like a UI issue in the build details page only:
image
I can see in the log that the correct tag got checked out:

+------------------------------------------------------------------------------+
| (1) git-clone@6                                                              |
+------------------------------------------------------------------------------+
| id: git-clone                                                                |
| version: 6.2.1                                                               |
| collection: https://github.com/bitrise-io/bitrise-steplib.git                |
| toolkit: go                                                                  |
| time: 2022-10-26T13:48:40Z                                                   |
+------------------------------------------------------------------------------+
|                                                                              |
INFO[13:48:40] Start installing (git-lfs) with apt-get      
INFO[13:48:40]  * [OK] Step dependency (git-lfs) installed, available. 
Config:
- RepositoryURL: git@github.com:pilvikala/tag-goof.git
- CloneIntoDir: /bitrise/src
- Commit: 7bfe924d89529f12d9b14b2465c2b4d8be5cabdd
- Tag: v5
- Branch: 
- PRDestBranch: 
- PRID: 0
- PRSourceRepositoryURL: 
- PRMergeBranch: 
- PRHeadBranch: 
- ResetRepository: false
- CloneDepth: 0
- FetchTags: false
- SubmoduleUpdateDepth: 0
- ShouldMergePR: true
- SparseDirectories: []
- BuildURL: https://app.bitrise.io/build/84663eab-83f0-4f59-90c1-4e04e9878ef0
- BuildAPIToken: [REDACTED]
- UpdateSubmodules: true
- ManualMerge: true

Could you check your logs and confirm?

In the meantime, I’ll report this UI issue to our engineering team.

I think the issue that dev_much is describing (same as my case) is that the tag is correct but is not working from any branch but main/master.
For example if the tag is pushed from release-2 branch, the build will be triggered but using main branch not release-2 branch.

Is there a way to make this happen or is currently a limitation on bitrise?

What you are describing looks like a bug. However, we are not yet able to reproduce this. Can you tell me based on what information you know that the build triggered is using the main branch instead of checking out the tag? Can you paste a snippet of your logs where the cloning happens?

Well for my specific case we are using Bitbucket (not sure if its an issue with the webhook), the thing is that with -tag: "v*" in the trigger map:

  • pushing a tag like “v0.5-test” from any branch nothing happen, not build is triggered.
  • pushing a tag like “v0.5-test” from main/master, the build is triggered:
+------------------------------------------------------------------------------+

| (1) git-clone@6                                                              |
+------------------------------------------------------------------------------+
| id: git-clone                                                                |
| version: 6.2.1                                                               |
| collection: https://github.com/bitrise-io/bitrise-steplib.git                |
| toolkit: go                                                                  |
| time: 2022-10-26T17:43:21Z                                                   |
+------------------------------------------------------------------------------+
|                                                                              |
INFO[17:43:21]  * [OK] Step dependency (git-lfs) installed, available. 
Config:
- RepositoryURL: git@bitbucket.org:organization/somerepo.git
- CloneIntoDir: /Users/vagrant/git
- Commit: 9e35ae7acc1c1b1eea483f8458941d4db071834d
- Tag: v0.5-test3
- Branch: 

Also tried adding - push_branch: release/*after the tag filter in the trigger map but no luck either.
Also, tried to use the web gui to trigger a manual build (without the push_branch: release/* on trigger_map) and the funny thing is it works:

+------------------------------------------------------------------------------+

| (1) git-clone@6                                                              |
+------------------------------------------------------------------------------+
| id: git-clone                                                                |
| version: 6.2.1                                                               |
| collection: https://github.com/bitrise-io/bitrise-steplib.git                |
| toolkit: go                                                                  |
| time: 2022-10-26T18:02:36Z                                                   |
+------------------------------------------------------------------------------+
|                                                                              |
INFO[18:02:36]  * [OK] Step dependency (git-lfs) installed, available. 
Config:
- RepositoryURL: git@bitbucket.org:organization/somerepo.git
- CloneIntoDir: /Users/vagrant/git
- Commit: 
- Tag: v0.5-test3
- Branch: release/0.5

So not sure why is not working when pushing the tag directly.

@speedlight I tried reproducing this with both Github and Bitbucket to see if there’s a difference or an issue with triggers or webhooks but I could not find any issue with any of them. It also looks like there may be a few issues causing this. Would you mind opening a support ticket? Please reference this thread as it may help getting to the resolution faster.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.