Daniel Santos_157bm4 Atlassian Team

Awesome! I'm glad that helps!

Hi @Vinh Hong I'm glad you found a workaround, but as I mentioned I was able to make it work in 6.9.2 with the same code you posted here. I noticed a strange thing, you have an error in line 77, but the code posted here don't have 77 lines. Maybe the error was in a different part that was omitted? If you don't want to…

Hi @James St-Pierre I'm not sure if there is an easy way to identify if a build is rerun in pipelines, but what you could use in your label is a Linux timestamp. You could create a variable and use it in your label to distinguish builds based on the time the ran. This would be the way to create the variable script: -…

Hi @[deleted] I think we will need to check both the error you get and how your script is configured to help you on this one. Can you share those with us?

Hi @Carol Serroul In fact from your description, I see that what you need is another job in the same plan you already had. As a test I suggest you the following: * Clone the old plan * In the cloned plan, create another job just to build the extra database and test it. If the tasks are similar you could even try to clone…

Hi @christok We have a docker task in Bamboo that can simplify running docker containers or building docker images. This is the reference document about this task: * Configuring the Docker task in Bamboo - Atlassian Documentation I don't think we will have something out of the box specifically for the purpose you need, but…

It might be an issue related to the plan key used for the plan permissions. Try changing plan: SPEC-PLAN to plan: VINNY-PLAN and let me know what happens. I was able to make it work with this change.

Hi @Carol Serroul Thanks for the structured description! To assure I understand your scenario I still need you to share a few things with me: * When you say jobs I assume you are talking about plan jobs, not two different plans to run each of the jobs, is that correct? * When staging succeeds you want to merge the code to…

Hi @Evecimar Silva I'm afraid your image has an entrypoint script responsible for some of the setting you need. Do you mind trying to call the entrypoint script manually at the beginning of the step where this is failing? This is one example of a different problem with possibly the same source:…

Hi @Rich Allen Great question! Pipelines will not call the wodby/drupal-php:7.2 docker entrypoint script. That script is the one responsible for setting the memory configuration you need. As a workaround, you can call the entrypoint script at the beginning of your Drupal step. The following should show the memory…

Hi @Vinh Hong , Thank you for raising this question. Why plan created in bamboo_specs/bamboo.yml is default to read only? The intention of this design is to be able to control the plan configuration only from the repository side. This allows you to always have a way to restore an old configuration and also assure your code…

I guess it was intended by design assuming that passed tests will not be reviewed. I'm glad to be helpful!

Hello @Jack Nolddor [Sweet Bananas] Thank you for the detailed description. It was very helpful! Once I read It I went right away to test it myself and observe the same behavior. Which is: If the test passes You will only see them reported in the left panel beside the pipeline step name. If the test fails You will see a…

Hi @ShowMgr_IT That is really strange. My suggestion is that we check if there is any user with admin permissions in your Bamboo DB, so you could use that user to reestablish the permissions in your instance. Please try this query directly to your Bamboo DB: <span>SELECT</span> <span>(</span><span>CASE</span>…

From what I understood of your description, the build should happen in feature/A not in develop. That branch is the one with the pull request and that is what needs to be adjusted in order to merge it later into develop. To build the develop branch you need to create a pipeline configuration there which is not related to…

Hi @[deleted] I was trying to reproduce this scenario and I was able to do it with by either removing the pipelines file or renaming it with different caps like Bitbucket-pipelines.yml (capital "B"). It could be any change that makes the file different from bitbucket-pipelines.yml which is the right name for it. Can you…

Hi @Niek Nooijens Welcome to our community! Bamboo YAML specs do not provide a specific feature for that, but you could use the strategy provided in this article which involves a Curl request to Bamboo: * Dowload Plan Artifacts - Atlassian Community In your case that would be a script task with that curl call. The…

Hi @Railan Barbosa, I just want to register here that you solved the issue by adding the user to Jira. I was able to check that through the link you shared in the description. Thank you for following up in that ticket with your findings.

I love to walk in places like this =] Nature is amazing and I don't understand how we some times are so disconnected of it. Thank for sharing your way to start the week!

I think that without competition there is no reason to overload our lives with tasks. But then we have people we love... and they will see us differently if you don't meet their expectations (which are not only from them but inherited from the group - team, society, ...). If we are not able to handle their disappointment…

I guess to achieve it we need to have happiness/harmony as a goal. In my opinion, we overload ourselves because we are always trying to improve our results in endless competition. Our work needs to be the best, our team needs to be the best, our company needs to be the best. Note that "the best" means competition with…

Hi @Amir You should run the remote agent with a version supported in our Supported platforms - Atlassian Documentation. The latest supported version is OpenJDK 1.8. The description you shared also happens when a remote agent is manually cloned (copying the folders and starting a new instance). This is because the GUID of…

Hi @Zoe Hart You don't need to rerun a build to redeploy its artifacts because Bamboo saves them in a different location called Global Storage if they were deployed at some point in time. I suspect that your artifacts were manually removed from Global Storage (<Bamboo_Home>/artifacts/globalStorage/<Artfact_ID>). This…

You are welcome @Jimmy Seddon! I'm glad to be helpful.

Thanks for sharing. The following variables are available during the deployment runtime and should help you with this: * bamboo_buildKey * bamboo_buildNumber * bamboo_buildResultKey * bamboo_planRepository_1_branch * bamboo_planRepository_1_branchDisplayName Example of content: bamboo_buildKey=COM-AST-JOB1…

Hi @Jimmy Seddon That is a good question. Bamboo and Bitbucket have different behaviors in such case. Bamboo It will use the username to define what user from the user repository corresponds to the user history available. If you change the user repository and the username is the same, other fields will not matter.…

Hi @Aditi Gaikwad Thank you for the answers, but I'm afraid we will need to check the DB to solve this one. The logs chuck I asked may help as well. As the last resource (considering no DB access), I would try creating a new plan manually with the same configuration just to avoid the issue.

Hi @Robbe Sneyders Thank you for sharing the detailed description of this scenario. I was able to reproduce it like you described and used your description to create a new bug [#19094] - Cascaded pull request does not trigger pipelines as expected on UI merge. We will now need to wait for our developers to triage it and…

I'm glad it helps you =]

Hi @Aditi Gaikwad That is a strange problem. I'll need to ask you a couple of questions to check if can help you with this problem. Please share with us: * Is this problem happening when multiple plans or just with this specific one? * Is it happening with multiple branches of just with a specific one? * If you clone this…