We have Artifactory Pro license version 7.27.10. As an Admin we don't see the Projects tab in the UI. Do we need the Enterprise or Enterprise+ license?
From Artifactory 7.17.4, Projects is enabled by default in the JFrog Platform for Enterprise and Enterprise+ subscriptions, as stated in the JFrog wiki page HERE
That said, from Artifactory 7.31.10, the JFrog Projects feature is supported on all JFrog Subscriptions, as follows:
All JFrog subscription types can create up to three projects in parallel to JFrog supporting extended usage of 30 projects for Enterprise subscriptions, and 300 projects for Enterprise+ subscriptions.
For further read please refer to HERE
Related
Can JFrog Xray be used to scan Maven artifact directly? All examples and resources I can find shows only Xray scanning Docker Images where it also scans layer with java application and its dependencies.
But can one scan Maven artifact directly even if its not part of any Docker images?
As you can se in the official JFrog Xray documentation, it supports many more technologies. NPM, NuGet, Docker and RPM just to name a few.
The artifacts are scanned regardless of what contains them, as long as they are hosted in a JFrog Artifactory repository that is configured to be scanned by Xray.
BTW, scanning is recursive, so if you have an NPM module in an RPM, it would also be scanned and reported.
Iam trying to deploy a dotNet app in Azure App Service, but it doesn't work because the default version of msbuild is at 14:
D:\home\site\wwwroot>msbuild /version
Microsoft (R) Build Engine version 14.0.23107.0
Copyright (C) Microsoft Corporation. All rights reserved.
14.0.23107.0
I've tried to modify the deploy.cmd with the msbuild 15 path but it doesn't work. How can i simply update the default msbuild version to be at 15 ?
thanks
This has been discussed here: https://github.com/projectkudu/kudu/issues/2350
D:\home>set msbuild
MSBUILD_15_DIR=D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\15.0\Bin
MSBUILD_PATH=D:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe
To use it you will need to have a custom deployment script with at least these two modification:
pass the msbuild15.3 directory to nuget (nuget4 has dependency on it):
nuget.exe restore "{your .sln file path}" -MSBuildPath "%MSBUILD_15_DIR%"
use msbuild15.3 to build and publish:
"%MSBUILD_15_DIR%\MSBuild.exe {your build arguments}"
Having mentioned that, Azure manages OS patching on two levels, the physical servers and the guest virtual machines (VMs) that run the App Service resources. Both are updated monthly, which aligns to the monthly Patch Tuesday schedule. These updates are applied automatically, in a way that guarantees the high-availability SLA of Azure services.
While critical OS information is locked down from access (see Operating system functionality on Azure App Service), the Kudu console enables you to query your App Service instance regarding the OS version and runtime versions.
Kindly checkout the document OS and runtime patching in Azure App Service for more details on this topic.
I've noticed a different repository structure for a conan repository in Artifactory.
1. Artifactory Enterprise 6.3.2
Repository Layout: conan-default
Repository strucutre: repository_name/conan_username/conan_package_name/version/channel
2. Artifactory Enterprise 5.4.6
Repository Layout: conan-default
Repository strucutre: repository_name/conan_package_name/version/conan_username/channel
Do you know why? Is it because the Artifactory version? I haven't found anything in Artifactory release notes related to the conan repository structure.
The default layout for conan packages was migrated in Artifactory 6, to match other package managers default layouts that put the user (organization) name first, as the most important classification of packages.
The migration should be automatic, and affect only the visual appearance in Artifactory web UI. If there is some other changes, or the conan client breaks (and this is the reason you are asking), then, it is a failing migration in Artifactory upgrade. It should be reported to JFrog and ask support to help recover it.
I know that artifactory oss version does not support hosting p2 repositories natively.
Is it hovewer possible to do it somehow without such support? I think you cannot get a pro version for free for open source projects?
If you want to have p2 or npm repositories natively you need the Artifactory Pro version.
There are not option to have a free Artifactory pro version without support for opensource projects.
If you don't want to buy Artifactory PRO, there are free alternatives.
We have our source code (ASP.NET Core) within a SVN repository. Now for Continuous Integration, we want to use TFS to build and deploy to Azure WebApp. We can't migrate our code to TFS.
Is this possible?
Subversion is a natively supported repository type when defining builds since TFS 2015 Update 1. You should be able to choose it on the "Repository" tab.
There is a walkthrough available on VisualStudio.com.
You can build code you manage in Subversion in TFS 2017. You must install the Subversion client on your build agents. Check: https://www.visualstudio.com/en-us/docs/build/define/repository#subversion
In the Repository of Build Definition, choose Subversion type: