BAMBOO SPECS ISSUE - Java specs SCAN does not set/rebuild Permissions
Asked by vpogrebi:

Related Bamboo Support request: BSP-40224 (<https://getsupport.atlassian.com/servicedesk/customer/portal/10/BSP-40224>).

Our team has noticed that when Bamboo server executes Java specs SCAN (without underlying repository Java class update) - permissions (Plan permissions of Buld plans and Environment permissions of Deployment plans) do not get set/rebuilt.

We have noticed two cases when this occurs:

1. Using "Scan" button within Linked Repositories --\> Specs Status tab
2. PUSH'ing any changes to the Linked Repository - that are NOT within a given plan's Java spec

... in other words - when Bamboo server executes specs using SCAN instead of executing Maven build.

This issue can be observed/replicated by following:

1. Create brand new (never existed) plans from repository-stored specs (using source code changes PUSH to a spec-enabled Linked Repository).
   * observe that plan Permissions match the ones defined in the specs
2. Delete some (or all) of the created plans in Bamboo
3. Without PUSH'ing any changes to the repo - force plans being rebuilt using Linked Repositories --\> Specs Status tab's "Scan" button
   * observe that plan(s) that have not been deleted - remain unchanged, but plan(s) that have been deleted (in step #2) get re-created, but without Permissions set
4. Making \*any\* change to a Java specs file corresponding to a given plan, and PUSH'ing changes to the repo - recreates/fixes Permissions

Same exact behavior occurs when instead of using "Scan" button (step #3 above) - some changes \***other than within deleted plan's Java spec file**\* are PUSH'ed to the repository (deleted plan's Java spec file is unchanged).

So... after discovering this issue, we need to find a way to enforce Maven build from Java specs file - each time SCAN is executed (both cases explained above).

Question:

***Does anyone know how to force Bamboo specs SCAN rebuild plan (and Permissions) from Java specs file - even if no changes are pushed to the specs?***


Answers:
author: Jeyanthan I
body: Hi Valeriy,

I see that this is being handled internally via [BSP-40224](https://getsupport.atlassian.com/servicedesk/customer/portal/10/BSP-40224) already and thus I'll choose not to answer them.

Just to answer your query on how to trigger repository scanning forcefully, I suggest you to run the below curl command to scan for changes in Specs. Replace the repositoryID with the respective Specs repository's ID.

```
curl -X POST -H "Content-Type: application/json" http://BambooHostURL:8085/rest/api/latest/repository/scan?repositoryId=3997710?
```

*Note: This REST call works only from Bamboo 6.5.x.*

Hope that helps.

Cheers,  
Jey

comments: author: vpogrebi
body: Thank you Jey,

Does this statement behave essentially the same as clicking on 'Scan' button in the Linked Repository's 'Specs Status' tab? From your comment ("... to scan for changes in Specs") - it sounds the same...

If this is so - then this is not what I have asked. My question was: "how to enforce Maven build from Java specs file - each time SCAN is executed?"

In other words, we need not to just scan for changes - but to unconditionally rebuild entire plan (and all related objects like Permissions) entirely from repository-stored Java specs.

Issue that we have encountered - is that Plan and associated Permissions objects can be altered (updated or deleted) via UI (outside of Java specs). This may result in the state of the plan differ from that defined in the specs (while the specs have not changed). When this is the case, simple specs "scan" does not "fix" the plan (does not restore it to the state defined in specs) - simply because specs have not changed. Only complete rebuild from Java specs (not from server cached XML specs) - can "fix" (remove) the changes.


Tags: permission

spec