Rodrigo Jimenez added a comment - 09/Feb/2022 10:59 AM - edited Code workaround requires python rest api libs. We run this task every week. from atlassian import Bamboo import os BAMBOO_URL = os.environ.get( 'bamboo_bamboo_url' , '') ATLASSIAN_USER = os.environ.get( 'bamboo_build_user' , '') ATLASSIAN_PASSWORD = os.environ.get( 'bamboo_build_user_password' , '') countdown = os.environ.get( 'bamboo_countdown' , '') EXCLUDED_PROJECTS = os.environ.get( 'bamboo_excluded_projects' , '').split(' ,') def get_all_projects(): return [x[ 'key' ] for x in bamboo.projects(max_results=1000)] def get_plans_from_project(proj): return [x[ 'key' ] for x in bamboo.project_plans(proj)] def get_branches_from_plan(plan_key): return [x[ ' id ' ] for x in bamboo.search_branches(plan_key, max_results=1000, start=0)] def get_results_from_plan(plan_key): return [x for x in bamboo.results(plan_key, expand= 'results.result' , include_all_states= True )] def project_build_cleanup(plans): for plan in plans: print ( "INFO: Inspecting {} plan" . format (plan)) #branches = get_branches_from_plan(plan) # for branch in branches: build_results = get_results_from_plan(plan) build_results.reverse() counter=1 for build in build_results: build_key = build.get( 'buildResultKey' ) or None build_number = build.get( 'planResultKey' ).get( 'resultNumber' ) or None if build_number: while counter < build_number: build_key = plan + "-" + str (counter) try : #next_result= bamboo.build_result(build_key=build_key) print ( "INFO: deleting build " + build_key) bamboo.delete_build_result(build_key=build_key) except Exception as inst: pass counter += 1 print ( "INFO: real result detected " + plan + "-" + str (counter)) counter += 1 last_counter=counter # Check for spec update builds up to the countdown, normally defined to the highest last build number in bamboo while counter < int (countdown): build_key = plan + "-" + str (counter) try : #next_result= bamboo.build_result(build_key=build_key) print ( "INFO: deleting build " + build_key) bamboo.delete_build_result(build_key=build_key) last_counter=counter except Exception as inst: pass counter += 1 if __name__ == '__main__' : bamboo = Bamboo( url=BAMBOO_URL, username=ATLASSIAN_USER, password=ATLASSIAN_PASSWORD, timeout=180) projects = get_all_projects() for project in projects: if project in EXCLUDED_PROJECTS: print ( "INFO: Skipping project - {}" . format (project)) continue print ( "INFO: Inspecting project - {}" . format (project)) results = [] all_plans_of_project = get_plans_from_project(project) project_build_cleanup(plans=all_plans_of_project)

Rodrigo Jimenez added a comment - 09/Feb/2022 10:56 AM I have a workaround python cleanup script but is takes several hours to run, depending on the amount of plans. The problem with these builds, is that they can not be retrieved with the rest api.

Rodrigo Jimenez added a comment - 09/Feb/2022 10:53 AM Please implement this. Is quite annoying for those that share one spec repo for all plans.  continuous pollution of build history ...

Bob Schleiger added a comment - 10/Dec/2020 5:13 PM This needs to be moved from a Suggestion to getting fixed.  This is causing real problems for our R&D teams.  Michael Smith, can you provide any additional info on your script to cleanup?

Renatas Mandrijauskas added a comment - 10/Dec/2020 12:48 PM Same here! Mono repo configuration. Change for a plan causes all of those unwanted events and they are hiding actually broken builds. Open dashboard and you see everything is geen, but then you realize it is Spec executions so you have to view each builds history to see last build result and that is very painful. 

Michael Smith added a comment - 08/Jul/2020 10:59 PM Yep I have the same problems as Egor.  So much so that we came up with a small script to cleanup all those unwanted spec events via a Bamboo API.  I really like Kevin's Idea of moving Bamboo Spec History to Audit Log somewhere.

Egor Efimov added a comment - 16/Dec/2019 5:42 AM We have a workflow with one specs-repository, which controls all builds and deployments. So creating/changing one repository spawns scan-results in all others. It would be lovely if we could hide all these scan-results from build-plans.

Kevin Matlock added a comment - 10/Sep/2019 8:41 PM - edited Instead of having an option whether or not to consider a Specs update event as part of the plan's  build output results (this is what I consider a plan's "builds" are for), it makes far more sense to simply show a 'Specs re-scan history' sort of list for the event that updates a given plan's specifications.  This could be added to the plan's existing Configuration -> Audit Log tab, and shown with the related scan event as we currently have under the Linked Repos -> Specs Status list.

Jack Chen added a comment - 31/Oct/2018 3:43 AM I think the title should be "Add option to have Specs update events NOT to be considered as a build"