initial commit

.gitignore

@@ -0,0 +1,5 @@
+.bitrise*
+.idea
+.vscode
+README.md.backup
+_tmp/

LICENSE

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2024 Ahmad Al Sufy
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -0,0 +1,93 @@
+# Jira Release Status Update
+
+This step automates Jira release management by updating the release status. It allows seamless marking of a release for deployment, with an optional draft setting. Ensure your Jira instance details, release ID, authentication token, and other necessary inputs are correctly configured for smooth integration with your CI/CD workflows.
+
+
+## How to use this Step
+
+Can be run directly with the [bitrise CLI](https://github.com/bitrise-io/bitrise),
+just `git clone` this repository, `cd` into it's folder in your Terminal/Command Line
+and call `bitrise run test`.
+
+*Check the `bitrise.yml` file for required inputs which have to be
+added to your `.bitrise.secrets.yml` file!*
+
+Step by step:
+
+1. Open up your Terminal / Command Line
+2. `git clone` the repository
+3. `cd` into the directory of the step (the one you just `git clone`d)
+5. Create a `.bitrise.secrets.yml` file in the same directory of `bitrise.yml`
+   (the `.bitrise.secrets.yml` is a git ignored file, you can store your secrets in it)
+6. Check the `bitrise.yml` file for any secret you should set in `.bitrise.secrets.yml`
+  * Best practice is to mark these options with something like `# define these in your .bitrise.secrets.yml`, in the `app:envs` section.
+7. Once you have all the required secret parameters in your `.bitrise.secrets.yml` you can just run this step with the [bitrise CLI](https://github.com/bitrise-io/bitrise): `bitrise run test`
+
+An example `.bitrise.secrets.yml` file:
+
+```
+envs:
+- A_SECRET_PARAM_ONE: the value for secret one
+- A_SECRET_PARAM_TWO: the value for secret two
+```
+
+## How to create your own step
+
+1. Create a new git repository for your step (**don't fork** the *step template*, create a *new* repository)
+2. Copy the [step template](https://github.com/bitrise-steplib/step-template) files into your repository
+3. Fill the `step.sh` with your functionality
+4. Wire out your inputs to `step.yml` (`inputs` section)
+5. Fill out the other parts of the `step.yml` too
+6. Provide test values for the inputs in the `bitrise.yml`
+7. Run your step with `bitrise run test` - if it works, you're ready
+
+__For Step development guidelines & best practices__ check this documentation: [https://github.com/bitrise-io/bitrise/blob/master/_docs/step-development-guideline.md](https://github.com/bitrise-io/bitrise/blob/master/_docs/step-development-guideline.md).
+
+**NOTE:**
+
+If you want to use your step in your project's `bitrise.yml`:
+
+1. git push the step into it's repository
+2. reference it in your `bitrise.yml` with the `git::PUBLIC-GIT-CLONE-URL@BRANCH` step reference style:
+
+```
+- git::https://github.com/user/my-step.git@branch:
+   title: My step
+   inputs:
+   - my_input_1: "my value 1"
+   - my_input_2: "my value 2"
+```
+
+You can find more examples of step reference styles
+in the [bitrise CLI repository](https://github.com/bitrise-io/bitrise/blob/master/_examples/tutorials/steps-and-workflows/bitrise.yml#L65).
+
+## How to contribute to this Step
+
+1. Fork this repository
+2. `git clone` it
+3. Create a branch you'll work on
+4. To use/test the step just follow the **How to use this Step** section
+5. Do the changes you want to
+6. Run/test the step before sending your contribution
+  * You can also test the step in your `bitrise` project, either on your Mac or on [bitrise.io](https://www.bitrise.io)
+  * You just have to replace the step ID in your project's `bitrise.yml` with either a relative path, or with a git URL format
+  * (relative) path format: instead of `- original-step-id:` use `- path::./relative/path/of/script/on/your/Mac:`
+  * direct git URL format: instead of `- original-step-id:` use `- git::https://github.com/user/step.git@branch:`
+  * You can find more example of alternative step referencing at: https://github.com/bitrise-io/bitrise/blob/master/_examples/tutorials/steps-and-workflows/bitrise.yml
+7. Once you're done just commit your changes & create a Pull Request
+
+
+## Share your own Step
+
+You can share your Step or step version with the [bitrise CLI](https://github.com/bitrise-io/bitrise). If you use the `bitrise.yml` included in this repository, all you have to do is:
+
+1. In your Terminal / Command Line `cd` into this directory (where the `bitrise.yml` of the step is located)
+1. Run: `bitrise run test` to test the step
+1. Run: `bitrise run audit-this-step` to audit the `step.yml`
+1. Check the `share-this-step` workflow in the `bitrise.yml`, and fill out the
+   `envs` if you haven't done so already (don't forget to bump the version number if this is an update
+   of your step!)
+1. Then run: `bitrise run share-this-step` to share the step (version) you specified in the `envs`
+1. Send the Pull Request, as described in the logs of `bitrise run share-this-step`
+
+That's all ;)

bitrise.yml

@@ -0,0 +1,102 @@
+format_version: 4
+default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
+
+app:
+  envs:
+  - BITRISE_STEP_ID: update-jira-release
+  - BITRISE_STEP_VERSION: "0.0.1"
+  - BITRISE_STEP_GIT_CLONE_URL: https://github.com/Ahmadalsofi/bitrise-step-update-jira-release.git
+  - MY_STEPLIB_REPO_FORK_GIT_URL: https://github.com/Ahmadalsofi/bitrise-steplib
+
+workflows:
+  test:
+    steps:
+    - script:
+        inputs:
+        - content: |
+            #!/bin/bash
+            echo "Just an example 'secrets' print."
+            echo "The value of 'A_SECRET_PARAM' is: $A_SECRET_PARAM"
+    - change-workdir:
+        title: Switch working dir to test / _tmp dir
+        description: |-
+          To prevent step testing issues, like referencing relative
+          files with just './some-file' in the step's code, which would
+          work for testing the step from this directory directly
+          but would break if the step is included in another `bitrise.yml`.
+        run_if: true
+        inputs:
+        - path: ./_tmp
+        - is_create_path: true
+    - path::./:
+        title: Step Test
+        description: |-
+          The example input has a default value,
+          you can overwrite it if you want to, just like we did below,
+          but the step would use the default value specified in the `step.yml`
+          file if you would not specify another value.
+        run_if: true
+        inputs:
+          - jira_username: $jira_username
+          - jira_token: $jira_token
+          - jira_url: "https://.....atlassian.net/"
+          - jira_release_id: "123456789"
+          - release_status: "true"
+          - release_date: "2024-01-22"
+    - script:
+        inputs:
+        - content: |
+            #!/bin/bash
+            echo "This output was generated by the Step (JIRA_RELEASE_UPDATE_SUCCESS): $JIRA_RELEASE_UPDATE_SUCCESS"
+
+
+  # ----------------------------------------------------------------
+  # --- workflows to Share this step into a Step Library
+  audit-this-step:
+    steps:
+    - script:
+        inputs:
+        - content: |-
+            #!/bin/bash
+            set -ex
+            stepman audit --step-yml ./step.yml
+
+  share-this-step:
+    envs:
+      # if you want to share this step into a StepLib
+      - MY_STEPLIB_REPO_FORK_GIT_URL: $MY_STEPLIB_REPO_FORK_GIT_URL
+      - BITRISE_STEP_ID: $BITRISE_STEP_ID
+      - BITRISE_STEP_VERSION: $BITRISE_STEP_VERSION
+      - BITRISE_STEP_GIT_CLONE_URL: $BITRISE_STEP_GIT_CLONE_URL
+    description: |-
+      If this is the first time you try to share a Step you should
+      first call: $ bitrise share
+
+      This will print you a guide, and information about how Step sharing
+      works. Please read it at least once!
+
+      As noted in the Step sharing guide you'll have to fork the
+      StepLib you want to share this step into. Once you're done with forking
+      the repository you should set your own fork's git clone URL
+      in the `.bitrise.secrets.yml` file, or here in the `envs` section,
+      as the value of the `MY_STEPLIB_REPO_FORK_GIT_URL` environment.
+
+      You're now ready to share this Step, just make sure that
+      the `BITRISE_STEP_ID` and `BITRISE_STEP_VERSION`
+      environments are set to the desired values!
+
+      To share this Step into a StepLib you can just run: $ bitrise run share-this-step
+
+      Once it finishes the only thing left is to actually create a Pull Request,
+      the way described in the guide printed at the end of the process.
+    before_run:
+    - audit-this-step
+    steps:
+    - script:
+        inputs:
+        - content: |-
+            #!/bin/bash
+            set -ex
+            bitrise share start -c "${MY_STEPLIB_REPO_FORK_GIT_URL}"
+            bitrise share create --stepid "${BITRISE_STEP_ID}" --tag "${BITRISE_STEP_VERSION}" --git "${BITRISE_STEP_GIT_CLONE_URL}"
+            bitrise share finish

step.sh

@@ -0,0 +1,59 @@
+#!/bin/bash
+
+# Function to check if a variable is empty
+check_empty() {
+  if [[ -z "$1" ]]; then
+    echo "Error: $2 is required but not provided."
+    exit 1
+  fi
+}
+
+# Check mandatory inputs
+check_empty "$jira_username" "Jira Username"
+check_empty "$jira_token" "Jira API Token"
+check_empty "$jira_url" "Jira URL"
+check_empty "$jira_release_id" "Jira Release ID"
+check_empty "$release_status" "Mark Release as Completed"
+
+echo "Updating release..."
+
+# Construct JSON payload
+JSON_PAYLOAD=$(cat <<EOF
+{
+  "id": "$jira_release_id",
+  "released": "$release_status"
+EOF
+)
+
+# Include releaseDate field if it's not empty
+if [[ -n "$release_date" ]]; then
+  JSON_PAYLOAD+=$',\n  "releaseDate": "'"$release_date"'"'
+fi
+
+JSON_PAYLOAD+=$'\n}'
+
+# Send the request
+RESPONSE=$(curl -s -X PUT -u "$jira_username:$jira_token" \
+  -H "Content-Type: application/json" \
+  -d "$JSON_PAYLOAD" \
+  "$jira_url/rest/api/3/version/$jira_release_id")
+
+# Define color codes for terminal output
+red=$'\e[31m'
+green=$'\e[32m'
+reset=$'\e[0m'
+
+echo $RESPONSE
+# Check if the Jira release update was successful or failed
+if [[ $RESPONSE == *"errorMessages"* ]]; then
+  echo "${red}❗️ Failed $RESPONSE ${reset}"
+  envman add --key JIRA_RELEASE_UPDATE_SUCCESS --value false
+  exit -1
+else
+  # If the update was successful, mark it as successful
+  name="$(echo $RESPONSE | jq '.name' | tr -d '"')"
+  variable=$( [ "$release_status" = true ] && echo "release" || echo "draft" )
+  echo "${green}✅ Success!${reset} $name release has been updated to $variable"
+  envman add --key JIRA_RELEASE_UPDATE_SUCCESS --value true
+  exit 0
+fi

step.yml

@@ -0,0 +1,85 @@
+title: |-
+  Jira Release Status Update
+summary: |-
+  Updates the release status in Jira, marking it for release. The step includes the option to set the release as a draft.
+description: |-
+  This step automates Jira release management by updating the release status. It allows seamless marking of a release for deployment, with an optional draft setting. Ensure your Jira instance details, release ID, authentication token, and other necessary inputs are correctly configured for smooth integration with your CI/CD workflows.
+website: https://github.com/Ahmadalsofi/bitrise-step-update-jira-release
+source_code_url: https://github.com/Ahmadalsofi/bitrise-step-update-jira-release
+support_url: https://github.com/Ahmadalsofi/bitrise-step-update-jira-release/issues
+
+type_tags:
+  - utility
+
+is_requires_admin_user: true
+is_always_run: false
+is_skippable: true
+run_if: ""
+
+toolkit:
+  bash:
+    entry_file: step.sh
+
+inputs:
+    - jira_username: ""
+      opts:
+        title: "Jira Username"
+        summary: "Provide your Jira username for authentication."
+        description: |
+          Your Jira username is required for authenticating Jira API requests. Ensure that you provide the correct username associated with your Jira account.
+        is_expand: true
+        is_required: true
+        is_sensitive: true
+    - jira_token: ""
+      opts:
+        title: "Jira API Token"
+        summary: "Provide the API token for authenticating with Jira."
+        description: |
+          The API token is used to authenticate and authorize the Jira API requests. You can generate a token in your Jira account settings.
+        is_expand: true
+        is_required: true
+        is_sensitive: true
+    - jira_url: ""
+      opts:
+        title: "Jira URL"
+        summary: "Provide the base URL of your Jira instance."
+        description: |
+          The Jira URL is the base URL of your Jira instance, excluding any specific paths. Make sure to include the protocol (e.g., https://) and any necessary port information.
+        is_expand: true
+        is_required: true
+        is_sensitive: false
+    - jira_release_id: ""
+      opts:
+        title: "Jira Release ID"
+        summary: "Provide the unique identifier for the Jira release."
+        description: |
+          The Jira Release ID is a required input that specifies the unique identifier associated with the Jira release.
+        is_expand: true
+        is_required: true
+        is_sensitive: false
+    - release_status:
+        type: bool
+        default: false
+      opts:
+        title: "Mark Release as Completed"
+        summary: "Specify whether to mark the Jira release as completed."
+        description: |
+          Set this input to 'true' if you want to mark the Jira release as completed, or 'false' otherwise.
+        is_expand: true
+        is_required: true
+        is_sensitive: false
+    - release_date: ""
+      opts:
+        title: "Release Date (Optional)"
+        summary: "Provide the release date for the Jira release."
+        description: |
+          The Release Date is an optional input that allows you to specify the date associated with the Jira release. This field can be left empty if not applicable.
+        is_expand: true
+        is_required: false
+        is_sensitive: false
+
+outputs:
+- JIRA_RELEASE_UPDATE_SUCCESS:
+  opts:
+    title: "Jira Release Update Status"
+    summary: "Indicates whether the Jira release update was successful or failed."