Category: New Feature

Suggest new licenses

VersionEye is monitoring now more than 1.2 Million open source projects and collecting all kind of meta information to this projects. One kind of the meta information is the corresponding license. Currently the VersionEye database contains licenses to more than 8 Million artefacts.

However, it is not always possible to fetch the license automatically. Sometimes things go wrong and sometimes the license is not available through a repository API. Sometimes human interaction is required to find the license for an artefact. Now everybody from the VersionEye community can suggest a license to an artefact. If you are on a VersionEye product page with an unknown license you will see a new “Suggest a license” link now.

screen-shot-2017-01-18-at-19-59-14

By clicking on the link you will come to a new page where you can suggest a license for the corresponding artefact and the form is already pre filled for you.

screen-shot-2017-01-18-at-20-01-36

By submitting the form above the VersionEye team will receive an email notification with the new license suggestion. After the submission was reviewed and approved the license will show up on the page.

I hope that many of you will use this new feature! 🙂

New icons for visibility scope and private projects

Up to now it was not obvious which VersionEye project is a “private” project. That means a project from a private GitHub or Bitbucket repository. Projects created through the VersionEye API are also considered as private projects. To monitor private projects you need to have a paid subscription. To make the private projects more visible we marked them with a lock icon in the project overview table!

Screen Shot 2017-01-12 at 14.38.59.png

In the example above the first 2 projects are private projects, they are created through the public VersionEye API and that’s why they are marked with the lock icon.

Don’t confuse “private” projects with the visibility scope. By default every project is publicly visible to everybody who knows the project URL. That makes sharing information very easy. But don’t worry your projects are NOT part of the search index, that means it will not pop up in search results! In the project settings you can limit the visibility scope to collaborators only.

Screen Shot 2017-01-12 at 14.26.58.png

That means that your project is only visible to members of your organisation. So if somebody knows the project URL and he/she is not member of your organisation he/she will not be able to see the project report! The projects which have limited their visibility are marked in the project overview with an broken eye, like the last 2 projects in the first image.

VersionEye Maven Plugin 3.11.1

Version 3.11.1 of the VersionEye Maven Plugin is out and here are the change logs. This release brings a couple improvements and BugFix!

BugFix

Assume you have a Maven multi module project with 3 modules. Now you add the VersionEye Maven Plugin to the parent pom and run mvn versioneye:create. That will create a new project with subprojects in VersionEye. Now on your CI system on each build you run maybe this goal: mvn versioneye:securityAndLicenseCheck. That will always update the VersionEye project with the current dependencies from your Maven project and check them for security vulnerabilities and license violations. Everything works so far.

Now you are adding a new Maven module to your Maven reactor build and the next execution of mvn versioneye:securityAndLicenseCheck will fail, because it will try to update an non existing module on the VersionEye server.

This bug is fixed now! Version 3.11.1 of the VersionEye Maven Plugin can handle newly added Maven modules. If a new module is added it will automatically create a new subproject for that on the VersionEye server.

Improved Merging

For Maven multi module projects one project is created for the parent pom and for each module a project is created on the VersionEye server and merged into the project for the parent pom. This merging process was working through the GAV coordinates of the parent pom. That was leading to problems if the same project was monitored twice on a VersionEye server. The new merge mechanism is independent from the GAV coordinates, it only relies on the project ID from the VersionEye API.

Support for Project License

The VersionEye Maven Plugin is resolving all dependencies locally and only sends a pom.json file to the VersionEye API, which contains only the needed information. Now this pom.json file also contains the license from the pom.xml file and the project license is displayed in the web interface.

Screen Shot 2017-01-12 at 13.31.55.png

 

Refactored Notifications

VersionEye is monitoring more than 1.2 Million open source projects by now. You can follow any of those OS projects at VersionEye and as soon a new Version of the followed package is release you will receive an email notification.

Facebook like notifications

The notifications which are created and send out to you are available in the web interface as well, but it was a bit hidden up to now. In the current version new notifications count is displayed with a red banner in the main menu. Just like you know it from Facebook and other social networks. Here an example:

screen-shot-2017-01-05-at-14-00-00

Directly next to “Organisations” in the main menu you can see a red 1. That means you have 1 unread notification. If you click on it you get to the notification view and the red notification count disappears.

screen-shot-2017-01-05-at-14-00-53

That way you see immediately if there are new releases out there. Even before you get the email 😉

Notifications via API

The notifications for new artefacts you are following are available via the public VersionEye API as well. It works exact the same way. If you have unread notifications the API will return a list of notification entities and each of the unread notifications will have the flag “read = false”. If you fetch the same resources again the “read” attribute will be on “true”.

screen-shot-2017-01-11-at-15-03-47

Beside that the API also returns the information if the notification was already send out vial email or not.

By the way. There is a new VersionEye – Slack connector which is already using this API Endpoint. With that you can receive the notifications directly into your Slack channel!

Leave a comment here if you have feedback.

New Team Notifications

VersionEye has already a concept for organisations and teams. Up to know it was possible to assign 1 team to multiple projects, but a project was always connected to exactly 1 team. The team members received All notifications in the period which was selected on the project. That was not ideal because specially in big organisations there are different groups of interests. Some people are only interested in  security notifications, some only in license notifications and others are maybe interested in version and security notifications. Beside that different groups of people want to get their notifications on different week days. Now all this possible!

Now the notification and period settings are not on the project level anymore. There are on the team level now. Each team can choose which notifications there are interested in and on which week days they want to receive the email notifications to that.

Maybe the developer team is interested in outdated versions and security vulnerabilities and they want to receive email notifications from Monday to Friday but not on the weekend. That would look like this:

team_notifications_01

The team “security_officers” is only interested in security notifications on every day of the week. That would look like this:

team_notifications_02

And now a project can be assigned to multiple teams. In the project settings tab, at the bottom, multiple teams can be selected which should be assigned to the project.

team_notifications_03

In the example above 2 teams are assigned to this project. Each team will receive email notifications for different aspects of the project, on different days of the week.

This new model offers much more flexibility and is a really good fit for big organisations with many teams and many projects.

Try it out and leave a comment here if you have feedback.

New Privacy Setting

If you have an account at VersionEye your username will show up in autocomplete fields. One of this autocomplete fields is for example in the teams view. If you want to add a new team member to your team you simply start typing their username and immediately you get usernames suggested like in this example:

screen-shot-2016-11-29-at-14-26-07

If you don’t want that your username shows up in the autocomplete fields, for privacy reasons, you can turn it off now. Simply go to your profile settings and then to “privacy”. Here you have an option “My profile shows up in autocomplete fields?” which you can turn off by selecting the value “No”.

Screen Shot 2016-11-29 at 14.26.30.png

After saving your new settings your username will not shop up anymore in autocomplete fields.

Screen Shot 2016-11-29 at 14.26.56.png

Try it out yourself and leave a comment if you like this feature.

 

Open Source Component Inventory

If you are working in a big company with many software projects it’s very likely that you are using many open source components as dependency. But how do you keep track of it? How many components are you using in different version of multiple projects? You don’t know? This are questions VersionEye can answer you in seconds.

If VersionEye is monitoring your projects you can take advantage of the “inventory” feature. Simply click on the “inventory” link in your organisation and VersionEye will show you ALL the open source components your organisation is using over all the projects which are monitored by VersionEye. That can look like this.

Screen Shot 2016-10-19 at 22.21.53.png

It’s long list of all the components and below each component you can see which of you projects are using it in which version. If a project is using an out-dated version of the component the line is marked yellow.

Here is another screenshot with some comments to the meaning.

Screen Shot 2016-10-19 at 22.21.53 2.png

That’s already pretty cool because this open source inventory list is generated in real time, it always shows you the current status of your projects. But the really cool thing is that you can filter the inventory by different criteria like:

  •  Teams
  • Language
  • Project Version
  • Duplicates

Let’s make an example. Assume you don’t wanna see the full list of components, you are only interested in open source components which are used in 2 or more different versions over different projects. In that case you would select “All teams”, “All languages”, “All versions”, “only duplicates” and hit the “Filter” button. The result would like similar to this.

screen-shot-2016-10-19-at-22-22-53

In the example above you can see that the component “versioneye-core-j” is used in 2 different versions over 4 different projects.

Now let’s say you only want to see duplicate open source components in the “developers” team. For that you would select the team “developers” in the first field and hit the “Filter” button. Here is an example.

screen-shot-2016-10-19-at-22-23-59

In the example above not ALL projects in the organisation have been analysed. In this example only the projects which belong to the “developers” team have been analysed and now we can see that testng is used in 2 different version over 2 Java projects and capybara is used in 2 different versions over 3 projects.

Now let’s say you want to see the open source dependencies of a team over all projects, but if a dependency is used by another team as well you want to see that as well. For that you would select for example “Team: developers”, “All languages”, “All versions”, “Show duplicates” and hit the “Filter” button.

screen-shot-2016-10-19-at-22-24-49

Now all the dependencies from the “developers” team have been analysed and in this example we can see that the component “versioneye-maven-plugin” is used by 2 projects in the “developers” team AND in addition to that in the last 2 rows we can see that this dependency is used by 2 other projects as well which are in a complete different team.

I hope this new filter options are helpful for your daily work. Leave a comment here if you have feedback.

Pull request support for GitHub

77% of all our signed up users are coming from GitHub and they use VersionEye to monitor their GitHub repositories. For a while now there is a VersionEye service hook in GitHub which calls back the VersionEye API on every git push event and updates the corresponding project in VersionEye with the latest dependencies from GitHub. But now you can use VersionEye to test your changes directly in a Pull Request and see the results of those changes in the GitHub Pull Request UI. This way you can even enforce rules that would prevent a Pull Request merge if a dependency is blacklisted or it is flagged with a security vulnerability.

Given that GitHub is moving away from Service Hooks towards native WebHooks, we changed our integration to do the same. If you are logged in to VersionEye with your GitHub account you can simply click the link “Create from GitHub” and navigate to a repository where you will see all supported project files and the corresponding branches. To monitor a project file simply flip the switch directly next to it.

Screen Shot 2016-08-16 at 14.05.48

In the example above the Gemfile in the develop branch is monitored by VersionEye and it works like this: Every time a new project file is imported from GitHub, VersionEye will automatically create a web hook on that GitHub repository, which will call back the VersionEye API on each “git push” event and if the monitored files are affected, VersionEye will re-parse the files and update the view in VersionEye immediately.

The cool thing is that this also works with pull requests! Assume somebody is forking your project, adding new dependencies and sends back a pull request. In that case the VersionEye web hook kicks in and checks if some of the dependencies have security vulnerabilities or unknown licenses.  For those cases, VersionEye will respond to the pull request with  a “failed” status message  and you can see the result directly on the GitHub Pull-Request tab, like this:

GitHub-pullrequest-VersionEye-check

By clicking on the “Details” link you can see a more specific report at VersionEye for that pull request.

gh-veye-02.png

A report like this is generated on every new commit which is added to the existing pull request. It’s similar to a build at TravisCI. Now you can still merge the pull request if you like but at least you are informed about security vulnerabilities and license issues.

In the VersionEye UI you will find a new sub menu “Pull requests” in the organisation view. Here are all commits from all pull requests are listed which belong to your organisation.

Screen Shot 2016-08-16 at 14.22.50

The interesting part here is how VersionEye is combining dynamic and static analysis. Your project is checked for security vulnerabilities and licenses on each commit and each pull request but also regularly independent from that. Even if there are no commits and no pull requests for a couple days, VersionEye will check your project once a day by default and send you an email if a new security vulnerability was found for one of your dependencies.

With this new feature the developers are getting instant feedback to their changes. In real time the dependencies are analysed and the developers informed. That saves a lot of Time & Money. We think it’s important to run this kind of analysis as early in the development process as possible. If your software is already bundled and published to a binary repository it’s too late for this kind of analysis because your software might be distributed already to a high number of devices/clients. Run your analysis as early and as often as you can 😉

And by the way, that’s all open source 😉 You can run the software on your own infrastructure and it works well together with GitHub Enterprise 🙂

This is a pretty new feature. If you find a bug or you have some kind of feedback, simply open a ticket here.

Improved proxy settings

We just improved the proxy settings in VersionEye again. If you spin up your one instance of VersionEye, you have to activate your instance with an API key. That step can already fail if you are behind a Proxy. Now in the newest version you can enter proxy setting already on the activation page.

Screen Shot 2016-08-15 at 14.07.49

If your instance is activate and you are logged in as admin you can change the proxy settings in the settings area.

Screen Shot 2016-08-11 at 09.48.50

Let us know how that works for you.

Proxy Settings for VersionEye Enterprise

If you run the VersionEye Docker Containers on your own Infrastructure, then it might be that you are behind a Proxy. Especially in big companies there is always a central Proxy between all internal machines and the Internet. Now there is a new form in VersionEye there you can configure your Proxy settings. If you are logged in as admin you will see a new menu entry in the settings “/settings/proxy”.

Screen Shot 2016-08-11 at 09.48.50

Here you can configure your Proxy settings. That is especially important for the daily sync to the public VersionEye API. If you VersionEye instance can’t reach the public VersionEye API in the Internet the sync mechanism will fail and your local database remains empty.