1.Is X-ray report generation possible using API Calls at the disired page in the Jfrog artifactory?
2.Scenario:Application dev team uploads the Build/Repository of their application into the Jfrog artifactory an xray scans it automatomatically. Suppose if we find vunerable Jars in perticular build -question-"can we corelate the vunerable jars to the respective builds and depedend builds and extract the same information in the report??
For Example: Vunerable Jar 'X' is used by build1 but the artifactory contains N no of Builds.
can we fetch the information if the same Vunerable Jar 'X' is used by multiple other build present in the artifactory. And is there any other way to intimate the build owners about this Vulnerable Jar 'X' which might be used on their application or Build.
Please find the answers to your queries below.
Yes, the report generation is possible through API calls made against the Xray service. [Xray REST API - Reports]
For the collection of data in accordance with the scenarios described in the second query, I believe this API call would be helpful.
Yes - This is documented in the Xray REST API documentation under the Reports section.
Yes, this is also specified in the Reports documentation, you can define the required scope and select multiple builds or repositories.
As for notifying build owners - This can be done by creating a rule for the policy that contains automatic action with the ability to inform the deployer and the watch recipients. This is triggered when there is a violation of the policy (which was previously created) Xray will generate a violation (for example jar X contains vulnerability with severity high)and it does not meet the policy and then Xray will generate notifications.
See relevant documentation.
Related
The company I work on recently purchased SonarQube Enterprise to improve code quality throughout all repositories. I found out that there is a feature that enables SonarQube to comment automatically on PRs targeting a specific branch, and I successfully managed to try that out.
Thing is:
That configuration is not scalable: I would need to manually configure every repo to follow that rule
That configuration needs a build pipeline to be defined "old school" on Azure DevOps to work, and we are moving into Pipeline as Code, starting of course with CI (where this takes place)
Anyone managed to get the PR commenting working in that scenario? Or, at least, solving the #1 problem?
Cheers
You can use REST APIs to do whatever configuration you need to do across your repositories. Refer to the REST API documentation.
Shouldn't matter, although I haven't tested it. The SonarQube tasks aren't aware of whether the build source is YAML or visual designer/classic/JSON builds. The underlying tasks and job running architecture is the same. As long as the build is hooked up to a branch policy, it should still work.
I am trying to integrate Percy.io, a visual regression testing tool with Github status check.
I have signed up for free account with Percy and paid Github version.
I wanted to setup status check with Percy with each pull request as below suggested at percy doc on status check
I have integrated Percy in Github
Added rules in Github
but still don't see check on pull request.
Added same project in percy.io too
Any Idea what I am missing over here?
It's hard to be specific without knowing more about your application, however one piece that seems to be missing from your setup is a CI/CD configuration.
Basically, you need a Continuous Integration service (such as Travis, Jenkins, CircleCI or others to trigger a build for your project so that percy can capture snapshots. Did you configure one?
See the documentation here.
Here an example configuration for one of my projects. Note that how you set this up may differ if you use a different set of tools than what's in the article.
Before going forward, I realize this question is too broad. But I couldn't figure out the proper verbiage to search either here in SO or on GOOGLE.
If this question is a duplicate, then please excuse me in advance and provide me the link to the original question.
Problem :
We are working on creating testing framework. One of the requirements is to publish a report at the end of the testing phase with build information. We need to provide information like who committed the latest change we are testing, what is the build version we are using for testing etc.
In our current setup, We are using github as SCM. Whenever there is a commit to the SCM, a build is triggered on Jenkins and if the build is successful, the jar is deployed to JFrog Artifactory. I am trying to come up with a gradle script to get the necessary information.
Any pointers to the following questions are highly appreciated:
Which plugin can I use to retrieve the info for a SNAPSHOT jar from Artifactory?
Which plugin can I use to retrieve Jenkins build info using the build number retrieved from Q1?
Not sure this is what you were asking for, but have you looked into the Artifactory Build Info file?
The Artifactory Jenkins Plugin can collect build information for you and publish that information to the Artifactory server (If you choose to "collect and publish build info").
The build information can then be viewed on the artifactory server and also fetched using a simple REST call.
HTH,
Or
I am relatively new to artifactory trying to achieve the below pointers.
1.) After QA approval trying to promote Jars from snapshot to release artifact(actual promotion works) but promoting to release artifact is not changing version name.
whether it is possible to change/rename artifact on rest api build promotion.?
2.) Also please suggest how we can achieve roll-back scenarios here.
Any inputs are greatly appreciated.
Thanks.
The build promotion REST API does support changing the version name.enter link description here
You can change the version name using a custom promotion user plugin. You can see some examples of build promotion plugins in the JFrog Dev Github account.
Specifically, the promotion.groovy plugin contains example of copying staging artifacts to release artifacts.
A good place to start is the user plugins wiki page and the Artifactory public API documentation.
The Artifactory Jenkins plugin supports more advanced release management capabilities, including the option to rollback.
I've been looking into artifact repositories for something that our release team can use for storing outputs of full builds from multiple projects. From what I've read, artifact repositories are mostly used for storing library files required for a build. My assumption is that their intended use is to ensure developers and build servers are using the exact same binary dependencies during build process.
Few questions:
Is it possible to store the build output of entire projects into an artifact repository (A full release), a place to store artifacts ready for deployment?
Is this common practice?
Is it possible to have analytics of what was changed since the last build? Ex: can I see which artifacts have changed since the last release?
So, the short answer to your questions are: yes, yes, and mostly yes.
While it is true that Binary Managers such as Artifactory are used for dependency management they are also used to host entire builds.
In Artifactory this can be easily achieved through the Build Integration features. If you are not using any CI server such as Jenkins (for example) you can use the JFrog CLI to upload your builds and their corresponding Build Info.
In addition, with regards to analytics, not exactly as such, but in Artifactory you have the option to perform Build Diff and see the changes between builds.
Hope I helped,
Eran
p.s. I work for JFrog
Using Sonatype Nexus woks for what you need, you are able to deploy not just Java artifacts (example: .ear, .jar, .war files) you are able to deploy any kind of binaries, we are using it for storing reports for Orace BI Publisher, or .exe binaries.
Is it possible to store the build output of entire projects into an artifact repository (A full release), a place to store artifacts ready for deployment?
Yes, as I said before, you can store any kind of binaries you want.
Is this common practice?
I don't know if it is a common practice, but in my case It helped us to keep an order. Just evaluate if it works for you.
Is it possible to have analytics of what was changed since the last build? Ex: can I see which artifacts have changed since the last release?
Sonatype Nexus handle a version for each artifact (or binary) so you are able to store all the "history" from your deployments, also it is able to handle security policy for example you could not deploy the same binary twice with the same version it forces you deploy a new version in this way you can verify when an artifact has changed, the date and who uploaded the artifact.
This is how it looks like: