I run a SonarQube scan on a Java maven project whith my Sonar server set as parameters.
But when the command line says it's done, it does not appear imediately on the SonarQube web UI nor via API. I need to wait from 1 to 3 minutes before the number of vulnerabilities increases.
I think there is a sort of post-analysis done when it's pushed to the server.
How can I know when this treatment is done ?
This is because I have another service that asks imediately the SonarQube API once the analysis is done on the machine, but it always returns 0 vulnerabilities since post treatment seems to not be done.
When the scanning work is done, the report link is provided, but right after the scan completes, SonarQube initiates a "background task" that does some things that are somewhat opaque. After that background task is complete, it is likely that your statistics are up to date.
Depending on how you run the scan, this "wait" is automatically managed for you. For instance, if you use Jenkins pipelines, you should be using the "withSonarQubeEnv" and "waitForQualityGate" pipeline steps. The latter goes into a wait loop, checking for the background task to be complete. It is also possible to use the SonarQube "WebApi" RESt service, which can be used to get the status of the background task. I would provide more info, but you haven't provided much info about the environment your scan is running in.
Related
I'm trying to setup the CI/CD setup of a mono repository using Google Cloud Build. We have a single Cloud Build trigger that starts a build on a new commit, it does some general steps and then then starts a build for every (micro)service in the mono repository using gcloud build submit.
This however means that if 4 or 5 people are push code to the repository roughly at the same time we can have around 50-70 concurrent builds running in cloud build. Which in itself isn't an issue for us. The only issues is that when this happens the following errors will popup:
{
“code”: 429,
“message”: “Quota exceeded for quota metric ‘Build and Operation Get requests’ and limit ‘Build and Operation Get requests per minute’ of service ‘cloudbuild.googleapis.com’ for consumer ‘project_number:<PROJECT_NUMBER>’.“,
“status”: “RESOURCE_EXHAUSTED”,
“details”: [{
“#type”: “type.googleapis.com/google.rpc.ErrorInfo”,
“reason”: “RATE_LIMIT_EXCEEDED”,
“domain”: “googleapis.com”,
“metadata”: {
“service”: “cloudbuild.googleapis.com”,
“consumer”: “projects/<PROJECT_NUMBER>”,
“quota_limit”: “GetRequestsPerMinutePerProject”,
“quota_metric”: “cloudbuild.googleapis.com/get_requests”
}
}]
}
In other words: We are running into quota limits. The quota only allows us to only make 900 operational requests per minute.
We already tried switching to private pools in the hope that the above quota limit was only there for when you don't use private pools, but this unfortunately still makes us hit the quota.
Now, I am trying to find out if I can decrease the amount of these operational requests.
A possible solution might be related to how I am using gcloud build submit. When you run gcloud build submit, it starts a new build, waits for the build to finish, and shows the output of the build. To achieve this, I presume that gcloud is making requests every few seconds to find out what the status of the build is. I suspect that these 'status' requests are why my Cloud Build quota limit is reached. Which is why I'm trying to see how I can lower the amount of these requests per minute.
One option is to simple decrease the amount of builds running in parallel, which is unfortunately not an option in my situation. If I execute them sequentially it simply takes more time than acceptable in my situation.
Another option would be to increase the time in between such 'status' requests. However, on this page I did unfortunately not find a CLI flag to alter this.
Note: I did find the --async flag, however that does NOT help me, since I still want the process to wait until the build has succeeded. And I also did find the --supress-logs, which also does NOT help me, since these requests presumably don't interact with Cloud Build but with the GCS bucket where the logs are stored.
The only option left that I can think off, is that I can start my builds with the --async flag and then manually request whether the build has succeeded using a longer interval. However I do feel like that is a lot of manual work that, for which I need to write some bash scripts that need to be maintained. This preferably isn't a path I would like to take unless really necessary.
Does anyone know of another way of achieving this?
If 4 or 5 people are push code to the repository
This shouldn't happen. The reason it shouldn't happen is because you should use the "push" trigger on the main branch, not on a development branch.
What do I mean by this?
I mean that building should occur on the main branch, which would correspond to joined effort of those five users and a responsible party in charge of unifying their changes.
So, really, your users should be pushing to the development branch, and pushes to main should be reserved for things that need to be built.
How can we work around this if we're only allowed one branch or are required to have updates visible on one branch?
My recommendation would be to use the tag filter, specifically filter the pushes by tag, as mentioned in the documentation. That way only the pushes person in charge of merging the changes will be built (assuming that this person pushes to the tag you've set)
TL;DR
Don't create push triggers for Cloud Build on a branch multiple people are working on. Either create it with a tag filter or have seperate development and main branches (people work on dev, builds are only made from pushes to main)
I've got a pipeline that logs in and logs out off a web-application every 5 minutes to ensure that the apps backend works, the database is up...
There occurred a problem that was not even related to the app directly, and my boss was bombarded with email-notifications. Is it possible to limit the emails that notify of a series of broken pipelines to only one, and suppress all subsequent emails until the pipeline has been fixed?
It seems that the editor for "Pipelines emails" is rather limited and doesn't support this directly. However, this option exists in Jenkins, and I'm wondering if someone figured out a solution or a workaround to achieve this in Gitlab CI. (Is it possible to script something like this in the ".gitlab-ci.yml"-file?)
I need a better way to use my alerting code.Right now I have a code that check for space free on aws ecs and sends a simple notification to slack if space is less than 5gb using slack api.I used this code in jenkins and setup a periodic schedule to run every 15 min.But once the notification is triggered I wanted it to stop the check for 4 hours so, it won't fill the slack channel with messages .So, i used sleep 14400 after condition is triggered.But this leaves an executor of jenkins waiting.Is there a better way to do this?
If you really want a better way, you should use better tools. there are many tools (some free) out there, that can monitor something in a stateful manner (for example, using a daemon).
Writing to log (or slack channel) in this context of using Jenkins is sort of stateless, for example you cannot check whether an alarm is currently triggered or not.
Since you cannot check if an alarm is already triggered - using jenkins with the logic you requested in your question ('snooze feature') can be very ugly.
In general I would recommend using Conditional BuildStep to trigger a step if a condition is met (i.e. if alarm not already triggered), but since there is no way for you to poll this information, or achieve this with Jenkins without the solution being 'hackish' like creating a file to indicate alert is on, and deleting it from another job if it was created more than 4 hrs ago - I would suggest looking at tools more suitable for the job.
We are testing an upgrade to Sonarqube5.3 and are having some of the issues identified in other StackOverflow posts, such as the Cobertura interactions. The problem I have is that I am not an administrator for the test server, so I can't look at the background tasks to find out why they are failing. Is there a way that the background task results can be printed in the sonar analysis logs? And is there a way to get the analysis in the build not to generate an exception when the background task fails, so that it just prints an error? Can the permissions for "view background tasks" be changed from just administrators?
The presumption is that non-admins don't care about background tasks except whether the most recent one has succeeded/failed.
Unfortunately, you're not going to be able to see server-side processing errors on the client side. The scanner compiles an analysis report and submits that to the server for processing, where it's queued and handled asynchronously.
What might work for you is requesting admin permissions, not on the SonarQube instance, but only on the project you're trying to analyze. That would give you access to the list of that project's background tasks (as well as the ability to administer the project more generally).
I have some long running integration tests that are automatically run by the TeamCity server when I commit to source control.
TeamCity allows me to prevent these tasks from taking up all the build agents concurrently by limiting the simultaneous builds, however I wonder if it's possible to have TeamCity cancel any currently running tasks of this configuration when a new one starts?
In this environment as soon as there is a new commit to source control, old runs of the integration tests are irrelevant, so I don't want the server to waste its time running tests for old versions.
I don't think this is possible, and I would say this is by design.
Imagine a world where this is allowed, you would never know which commit caused a test to start failing. If you had enough overlapping commits you could have 50 builds before you know that the final test to be run fails, and would have no idea whether it was the last commit or the one 49 before that which caused it to fail.
IMHO you would be better focusing efforts into making so that multiple runs can happen simultaneously on different servers, to get the speed up you want, not throwing the baby out with the bath water
UPDATE
Whilst I don't think this is supported out of the box, if I had to do this I think I would look at getting a notification when a build starts (seems there are no notifications for builds being queued, so you'll have to allow multiple builds to run concurrently for this to work) and then you can use the API to do cancel the other builds:.
you can get a list of builds using the API as well so should be able to cancel all the ones which are not the most recent
No, it's not possible. You can cancel it manually. Or you can add a quiet period (default is 60 seconds) so a build doesn't start immediately when something has been pushed. Then if some commits arrive after few seconds or minutes, they will be included in the TeamCity build.
My solution is similar to Sam's update but I would use a "preamble" configuration that is triggered by commits to source control. This job is solely responsible for checking to see if any of your integration test jobs are already running and stopping them with a REST API call, as needed.
The main integrations tests are run from a dedicated job configuration that uses a build finish trigger associated with the preamble configuration.
This setup makes it quite straightforward to query which jobs are running and may need to be cancelled if there is newer work to do. So the steps become:
Preamble - cancel any running integration test job, triggered by VCS
Integration test - triggered by completion of a "Preamble" build