Uploaded image for project: 'Bamboo Data Center'
  1. Bamboo Data Center
  2. BAM-15082

Enable environment deploy button only after the build is approved

    • 2
    • 6
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Nowadays, the Approved button is clicked when a build is validated and determined to be a release candidate to production. However, nothing stops someone from pushing the button to Production without the approval.

      There should be a way of enabling a specific Environment deploy button only when a build is approved.

          Form Name

            [BAM-15082] Enable environment deploy button only after the build is approved

            Subramanian Olagappan added a comment - - edited

            I wrote a script task to give better control for deployment to production env. This is tested in RHEL and need curl, jq to work. This can be useful to others till we have permission control the release approval button.

            I created the rel_approver variable as global variable with the format :xxxx:yyyy:zzzz: and run this script task before the actual deploy command.

            project_id=$(curl -s -u $bamboo_api_user:$bamboo_api_user_password http://bamboo/rest/api/latest/deploy/dashboard  | jq --arg project_name "$bamboo_deploy_project" '.[].deploymentProject | select(.name==$project_name) |  .id')
            
            if [[ !  -z  $project_id  ]]
            then
              echo project id $project_id
              version_id=$(curl -s -u $bamboo_api_user:$bamboo_api_user_password http://bamboo/rest/api/latest/deploy/project/$project_id/versions  | jq --arg version_name "$bamboo_deploy_version" '.versions[] | select(.name==$version_name) |  .id')
            else
              echo "ERROR: Project ID not found"
              exit 1
            fi
            
            if [[ !  -z  $version_id  ]]
            then
              echo version id $version_id
              version_status=$(curl -s -u $bamboo_api_user:$bamboo_api_user_password http://bamboo/rest/api/latest/deploy/version/$version_id/status | jq -r '.versionState' | tr '[:upper:]' '[:lower:]' )
              approver_id=$(curl -s -u $bamboo_api_user:$bamboo_api_user_password http://bamboo/rest/api/latest/deploy/version/$version_id/status | jq -r '.userName' | tr '[:upper:]' '[:lower:]' )
            else
              echo "ERROR: Version ID not found"
              exit 1
            fi
            
            if [ "X$version_status" == "Xapproved"  ]
            then
              echo Release $bamboo_deploy_version is $version_status by $approver_id
            else
              echo "ERROR: Release $bamboo_deploy_version is not APPROVED"
              exit 1
            fi
            
            if [[ $bamboo_rel_approver =~ :$approver_id: ]]
            then
               echo "Continue with deploy job"
            else
               echo "ERROR: $approver_id is not authorized to approve the release $bamboo_deploy_version"
               echo "Authorized users are $bamboo_rel_approver"
               exit 1
            fi
            

            Subramanian Olagappan added a comment - - edited I wrote a script task to give better control for deployment to production env. This is tested in RHEL and need curl, jq to work. This can be useful to others till we have permission control the release approval button. I created the rel_approver variable as global variable with the format :xxxx:yyyy:zzzz: and run this script task before the actual deploy command. project_id=$(curl -s -u $bamboo_api_user:$bamboo_api_user_password http: //bamboo/ rest /api/latest/deploy/dashboard | jq --arg project_name "$bamboo_deploy_project" '.[].deploymentProject | select(.name==$project_name) | .id' ) if [[ ! -z $project_id ]] then echo project id $project_id version_id=$(curl -s -u $bamboo_api_user:$bamboo_api_user_password http: //bamboo/ rest /api/latest/deploy/project/$project_id/versions | jq --arg version_name "$bamboo_deploy_version" '.versions[] | select(.name==$version_name) | .id' ) else echo "ERROR: Project ID not found" exit 1 fi if [[ ! -z $version_id ]] then echo version id $version_id version_status=$(curl -s -u $bamboo_api_user:$bamboo_api_user_password http: //bamboo/ rest /api/latest/deploy/version/$version_id/status | jq -r '.versionState' | tr '[:upper:]' '[:lower:]' ) approver_id=$(curl -s -u $bamboo_api_user:$bamboo_api_user_password http: //bamboo/ rest /api/latest/deploy/version/$version_id/status | jq -r '.userName' | tr '[:upper:]' '[:lower:]' ) else echo "ERROR: Version ID not found" exit 1 fi if [ "X$version_status" == "Xapproved" ] then echo Release $bamboo_deploy_version is $version_status by $approver_id else echo "ERROR: Release $bamboo_deploy_version is not APPROVED" exit 1 fi if [[ $bamboo_rel_approver =~ :$approver_id: ]] then echo "Continue with deploy job" else echo "ERROR: $approver_id is not authorized to approve the release $bamboo_deploy_version" echo "Authorized users are $bamboo_rel_approver" exit 1 fi

            Jamie added a comment -

            Definitely. We should be able to set-up rule(s) on an environment for this sort of thing.

            Approved-only releases is a must. Currently it is FAR FROM OBVIOUS when you run a deployment whether a release has been marked as Approved or Broken. It should be way more obvious, especially if you are trying to deploy a release marked as Broken.

            A nice to have would also allow enforcement that a release has been deployed to X environment before it is allowed to be deployed to Y.

            Jamie added a comment - Definitely. We should be able to set-up rule(s) on an environment for this sort of thing. Approved-only releases is a must. Currently it is FAR FROM OBVIOUS when you run a deployment whether a release has been marked as Approved or Broken. It should be way more obvious, especially if you are trying to deploy a release marked as Broken. A nice to have would also allow enforcement that a release has been deployed to X environment before it is allowed to be deployed to Y.

            Joe Levis added a comment -

            Yes please!

            I've seen this come up several times in different Atlassian forums. I see this as a major need, especially as more and more companies try to implement Continuous Delivery principles in their release pipelines.

            Joe Levis added a comment - Yes please! I've seen this come up several times in different Atlassian forums. I see this as a major need, especially as more and more companies try to implement Continuous Delivery principles in their release pipelines.

              851f15845f55 Mateusz Szmal
              fkraemer Felipe Kraemer
              Votes:
              38 Vote for this issue
              Watchers:
              28 Start watching this issue

                Created:
                Updated:
                Resolved: