Daniel Santos_157bm4 Atlassian Team

I'm glad you could find out the solution yourself =] Thank you for coming back to share it with others. See you in the next thread!

Hi @Lukasz Zasada I see you've filed a support case in our portal as well. As our support team shared with you, this problem is caused by a bug: [BAM-17507] DotNet Plugin: tab with NCover results not working. We will need to wait for our team to fix this one so you can move forward using NCover integration. 

Hello @max * Can you confirm this configuration is failing for Bamboo? * If yes, can you try using the JNDI configuration as configured for Google in this document: Configuring Bamboo to send SMTP Email. Some mail servers have their own specifications that may cause this configuration to be tricky. If you want to double…

Hi @Jeremiah Alfrey Thank you for explaining in details what you have done so far. Let me ask you some questions from your comments: While importing the data from the dump I got several errors. * Are the Postgres instance versions matching (source and destination)? * What were the errors you saw? * Did you stop Bamboo…

Hi @RajVerma7099 If you think this answer can help others, please click this helped me at the top of it. See you in the next thread!

Hi @Bjorn Harvold That is the way I see it could work, still using the Bamboo checkout task. Yes, you will need to change the origin of every build. Other option would be cloning the repository manually using a script task and taking control of the whole process involving the git repository. Please keep in mind that the…

Hi @Mikkel Thomsen I was not able to see your messages during the weekend but I'm glad that you found your own way to solve the issue. Yes, Bamboo does not support MariaDB, although some users (like you) will find their way to make it happen. Thank you for accepting the answer. See you in the next thread!

Hi @Mikkel Thomsen The following error line usually happens when there are multiple Bamboo processes running in the same server, therefore, locking part of the installation process: 2019-04-03 15:55:18,215 INFO [performSetupDatabaseConnectionBackgroundThread] [SharedFileLocker] Database…

Hi @RajVerma7099 I was able to reproduce the issue both in Bamboo 6.8.0 and 6.8.1. I've opened a new bug to report this thanks to you: * [BAM-20390] Scheduled triggered deployment is not able to download artifact after specs update Unfortunately, the only workaround I can possibly think is to set a scheduled trigger for…

Hi @RajVerma7099 Sorry for the delay. I still have to run some tests, but I think you are affected by this bug: https://jira.atlassian.com/browse/BAM-19770. As soon as I have them run I'll share my findings here.

Have you found any errors in your logs related to this event? You need to open the log file and search for the error you shared. You could search for "Only artifact items are supported". What I need is any stack trace prior to this one that might be related to this issue. This thread is public, so you will need to get just…

I think you are right, the checkout task may be expecting something different from the git repository configuration. Thoughts? Yes, please try to check the option Force Clean Build in your source code checkout task or add the task Clean working directory at the beginning of your job. That should work around this problem.

If you think this answer can help other users, please click the button "this helped me". See you in the next thread!

Hi @Jimmy Seddon Thank you for explaining in details what is your scenario there. I totally get why you need custom run for deployments allowing you to set the variables previously, even though this feature is not available. We do have an old feature request for this at [BAM-13707] Parameterised variables for Deployment…

Hi @John Thank you very much for your feedback and comprehension. Yes, I didn't quite understand your reply and thought you were talking about a different issue. It all makes sense now. Thank you for taking the time to clarify it. I've raised the flag to https://jira.atlassian.com/browse/JSWCLOUD-16754 internally and now…

Hi @neha.chauhan I was reviewing this thread and I'm still confused on what is the behavior you see there. It might be the case that a deeper investigation with the support team needs to take place. You say the agent is idle and that other agents are taking the builds. That seems to me just a matter of setting the right…

Hi @Bjorn Harvold Have you tried leaving only the origin configured? I don't know how Sentry works and extra entries might be confusing it. Maybe it worths a try.

Hi @Jiri Zahradka Can you check if there are any other concerning errors in your logs prior to this one? Please check the file <Bamboo_Install>/logs/catalina.out (or bamboo-stdout.<DATE>.log in case you use windows). If we can't get better clues from it we will need to open a ticket with our support team to investigate it…

Not that I'm aware of, unfortunately.

Hi @RajVerma7099 Can you share the Bamboo version so I can run a test to check if this is a bug?

Hi @Gareca Nanda I don't use silkCentral, but I want to share my 2 cents on this error with you. It looks like this issue is not really related to Bamboo. I can see that the Gradle build is failing in line 43 which is probably when you are trying to call silkCentral. Can you try running this build from your Bamboo Server…

Hi @Steven Tay Bambo uses the agent UUID to identify each agent and authenticate it. The agent will be approved or not and its references on capabilities will be kept based on that UUID. It means that if all your agents have the same UUID only the first one to authenticated will be able to take builds.

Hi @buradeshruti I just wanted to highlight, both plugins you shared are from third-party developers and are not even supported by them. Answering your questions: 1) Can we mark the manual stage as failed in Bamboo? No, you will need to change the build, to make it fail and rerun it to change the build result. 2) Does…

Hi @Bjorn Harvold I shared two links with you. In the first one, the solution comes from setting a central repository. In the second one, it comes from setting a new origin. What happens if I set remote origin back to its original Bitbucket location? Will Bamboo barf? I don't think that is a big deal, it should work in my…

Hi @kamuffe We will need to investigate this one further and given the type issue you are facing we understand that the best channel for troubleshooting it is our support portal. I've opened a support ticket in your name to report this problem and you should receive a notification about it soon. I kindly ask you to share…

Hi @Le Phuong As you can see in the support ticket you already submitted to our team, this is indeed a bug, more precisely this one [BCLOUD-17676] - Pull-request pipelines run with [skip ci]. The branch builds will be skipped but the pull request build will still run, unfortunately. I think that explains this behavior.

Hi @RajVerma7099 I'm not really sure if I understand your request. Could you give us more details on what configuration you have (plan/deployment) and what is the issue? Is your trigger in the build plan or in the deployment one? What is this variable standing for?…

Hi @Subhi Andrews Let me try to explain the issue you are facing after some tests I've run. Bitbucket is capable of handling multiple connections at the same time for pushes, which does not mean they will succeed. Every time you try to push code to a repository that has changes you didn't fetch before will cause the push…

Hi @Bjorn Harvold Like I shared before, I'm not sure how Sentry works. I just shared a suggestion to set the remote repository configuration once I know that Bamboo uses a shared repository. I think that you should try seeking for Sentry direct support. This seems to be their channel https://sentry.io/contact/support/.

Hi @Le Phuong Can you confirm that the [skip ci] token is part of your merge commit for the pull request?