Add git tag and git commit to parameters

[ghost]

Prefix

Hi guys!

Firstly, big thanks for this project as it helped me setting up stable CI/CD workflow via Gitlab and Bitrise.

Secondly, the issue I am submitting is a suggestion, which I already implemented for myself. It relates to the way Bitrise clones project.

Suggestion

As title of the issue says, I propose to add options to refer repository by either tag or commit hash, which is officially supported - check Bitrise API) and their manual on referencing repo by tag or commit hash.

Reasoning

My personal use case, that has driven me to implement this functionality, is that I wanted to trigger certain Bitrises's "beta" workflow for my iOS project, only when pushing new tag to the repo, as I got used (therefore, Bitrise should reference project by this exact tag). Current state of Gitrise project did not fullfill my needs, as it only allows to reference repo by branch, which instantly limits opportunities to trigger Gitlab's pipeline only by merge requests and pushes, because to take branch name in pipeline's job, it should be present in predefined variables (otherwise you must write some kind of branch-name-extracting script before running gitrise.sh). Gitlab's Predefined Env Vars says:

...

$CI_COMMIT_REF_NAME - The branch or tag name for which project is built

...

$CI_COMMIT_BRANCH - The commit branch name. Present only when building branches.
...

Which means that branch name is not built-in functionality.

Also, as I decided to implement tag-referencing functionality, the subsequent decision was to implement referencing by commit_hash, as it relates to same section of build_params of Bitrises's build trigger API and combined with both branch and tag parameters completely covers repo referencing configuration for this endpoint.

Implementation

1. Added two parameters to be parsed when executing gitrise.sh:

• -c or --commit - to set the Git Commit Hash to reference repo by
• -T or --tag - to set the Git Tag to reference repo by (capital T is used to not interfere with -t flag which enables test logs)

2. Included description of these params to usage() function (triggered by zero params or -h flag)

3. Extracted "build_params" content of json payload of request to trigger build to script's variable $BUILD_PARAMS in order to separate configuring build parameters from this step

4. Created a function that prepare_build_params() that sets up this variable

5. Made parameters --commit, --tag, --branch mutually exclusive to and prioritized them in order.

Contribution checks

• Ran shellcheck against my version of script
• Written tests

Postfix

I already implemented for my purposes and so I am looking forward to adding this functionality to Gitrise project. In case owners of this project are interested in this issue resolving, I will setup tests and submit a pull request.

Thanks!

[alexist]

See PR #26

[Azbagheri]

Hey @be4rd,
Sorry for the long delay. A lot has been going on and I just managed to go through the open issues.
First, thank you for your interest in Gitrise! Glad to hear it has been helping you as well!
Also, thank you for your detailed explanation of the new feature. It does make sense and I was wondering if you are still interested in opening a PR for it.

[Azbagheri]

Hey @alexist, I appreciate you submitting the PR. However, @be4rd 's solution is more complete and fits our project a little better.

[alexist]

Hello,

no problem. I made this PR because i need these feature on my project.

By the way, i made some change on my PR and now my gitlab pipeline as only one job that works for branch and tag

deploy:bitrise: 
  stage: deploy
  script:
    - ./gitrise.sh -w $WORKFLOW -a $BITRISE_ACCESS_TOKEN -s $BITRISE_APP_SLUG -b $CI_COMMIT_BRANCH -c $CI_COMMIT_SHA -T $CI_COMMIT_TAG

[Azbagheri]

Hi @alexist,

Glad to hear Gitrise is helping you as well!!

Regarding the different building options: tag, commit, and branch, I should mention that you can pass as many of them as you want, but Bitrise will only use one of them and that makes sense. At the end of the day, tags and branches are just a pointer to a commit. When cloning a project, Bitrsie will choose the checkout option according to its priority list which is as follows: commit, tag, branch. This means if you pass a tag and a branch to Gitrise, Bitrise will only use the tag. Even if you pass all three of them and they all have valid values, Bitrise will use the commit. But then again, you should only pass one of these options to Gitrise.

Once again, thank you for opening the PR. Because of all the interest in this feature, I looked into it myself and updated Gitrise to support different build options. You can now trigger a build for a branch, a commit, or a tag!! For now, the updates are only available on develop branch. Will release a new version of Gitrise tomorrow. In the meantime, feel free to try it out and let me know how it works out for you!!

[alexist]

Hi,

unfortunately, passing empty tag to bitrise has a side effect that i didn't see at first. When you want to filter builds by tag on bitrise builds page, you will see builds with empty tag.

The proper way seem to had tag only if tag is not empty, this is why i ended with this code :

    if [ -n "${TAG}" ]; then
      payload=$(echo "$payload" | jq  ".build_params +={\"tag\": \"${TAG}\"}")
    fi

About branch + commit option, i also have a requirement to filter builds by branch on bitrise. But my pipeline trigger build by commit hash to handle concurrent build on same branch. If i didn't set branch option, i don't think i can filtert by branch (a commit hash can be in many branches).

(I'v not yet tested your change)

[Azbagheri]

Hi @alexist,

I’m not sure how exactly you are intending to use Gitrise. But to clarify how it should be used with different build options, I’ve updated the README and have added some example use cases there. Hope you find that helpful!

I’m closing this issue since it was originally opened to request support for building a tag or a commit and that is done now. If you are still having problems using Gitrise or are interested in a new feature, please open a new issue so that we can discuss it there.