Issues with Artifactory after upgrade to 3.4 - artifactory

I followed the upgrade notes to upgrade from Artifactory 2.6.6 to 3.4.2, I reimported the artifacts but after that, artifact resolution often fails with 404.
Even previously deployed artifacts can not be resolved. The deploying Jenkins job runs fine, but when I open the URL from the log, I get that message:
{
"errors" : [ {
"status" : 404,
"message" : "Artifact not found: my/group/myapp/0.9.13-SNAPSHOT/myapp-0.9.13-SNAPSHOT.pom"
} ]
}
I also tried to export/import the whole system after upgrade, but nothing changed.
Does anyone know how to fix this?

I found out that the issue is related to the unique snapshot behaviour of Maven 3. In fact, there is no myapp-0.9.13-SNAPSHOT.pom, but one with a timestamp. The Rest API does not cover that and not all Jenkins plugins have support for that.

Related

Unable to build cordapp with accounts dependencies

I was able to build a cordapp using Accounts by following the steps at https://github.com/corda/accounts.
This cordapp was building and running until 03/16/2020, but since 03/20/2020 I am seeing errors in my CI builds because https://ci-artifactory.corda.r3cev.com/artifactory/corda-lib-dev/com/r3/corda/lib/accounts/accounts-contracts/1.0-RC04/accounts-contracts-1.0-RC04.jar cannot be accessed. I get a 409 response now, how can I resolve this?
{
"errors" : [ {
"status" : 409,
"message" : "The repository 'corda-lib-dev' rejected the resolution of an artifact 'corda-lib-dev:com/r3/corda/lib/accounts/accounts-contracts/1.0-RC04/accounts-contracts-1.0-RC04.jar' due to conflict in the snapshot release handling policy."
} ]
}
My build.gradle has
accounts_release_version = '1.0-RC04'
accounts_release_group = 'com.r3.corda.lib.accounts'
confidential_id_release_group = "com.r3.corda.lib.ci"
confidential_id_release_version = "1.0-RC03"
repositories {
maven { url 'http://ci-artifactory.corda.r3cev.com/artifactory/corda-lib-dev' }
maven { url 'http://ci-artifactory.corda.r3cev.com/artifactory/corda-lib' }
}
My local builds on my development environment work fine, I assume because I already have the jars in my .m2
Artifactory configuration has been changed to enforce separation between release and snapshot repositories. corda-lib-dev is a snapshot repo and CorDapp developers should not be developing against these.
Releases and release candidates will be available in corda-lib going forward.
Kindly use corda-lib, and develop again release 1.0.
The pom file with RC04 is set to return 409. I assume Corda's way to disallow use of RC04. May be RC03 is also the same. I just tried this today and saw the repository pom files.
Use "1.0" instead of "1.0-RC03"

Issue declaring the Nexus3 repositories as remote repositories in Artifactory

I am setting up Nexus3 repository as a remote repository in Artifactory.
But when I update the Nexus3 repo URL(https://domainname/repository/reponame/) & necessary credentials for authentication in the admin section, during testing i am getting,
Connection failed: Error 404.
I have tried providing the rest URL(http://domainname/service/rest/repository/browse/reponame).
In this case, connection to the nexus server establishes successfully & able to see the directory structure for the remote repo in the Artifacts section , but could not find the artifacts inside & seeing below output/error,
{ "errors" : [ {
"status" : 404,
"message" : "Couldn't find item: XXXX:XXXXXXX" } ]
You have to ignore the error while saving. This is because of a header mismatch.
Repo path should be like:
https://<host>:<port>/repository/reponame
Once you save the repository and try to download, it will work.
The test is failing when creating an Artifactory remote repository which point to a hosted Nexus repository, since Artifactory is using a HEAD request for checking the remote repository and for some reason Nexus will return a 404 (while returning a 200 when the same request is sent using the GET method). This behavior does not happen with Nexus group repositories.

Instalation of Intershop 7.9 failing on missing version for demo cartridges

I'm trying to install a demo shop of Intershop version 7.9 but i'm failing to get it working. When I run "gradlew deployServer" I'm getting an error on all dependencies of the first demo shop cartridge:
Could not resolve all dependencies for configuration ':app_sf_responsive:compile'.
Could not resolve com.intershop.business:ac_ecircle:.
Required by:
nl.test.testproject:app_sf_responsive:1.0.0-LOCAL
No version for module 'com.intershop.business:ac_ecircle' in project properties and no version declared in dependency. Consider adding a version or filter property to 'C:\projects\test7.9\projects\testproject\gradle.properties'
I have followed the complete Intershop manual Setup CI Infrastructure but there is one point I don't know exactly what to do, that's with the new versioning plugin.
It is in chapter 6.2.5, any one have an idea how to configure that?
After loads of tinkering and mails back and forth with Intershop support I found a solution.
My alterations are in section 7.2.4 of the Setup CI Infrastructure of Intershop:
https://support.intershop.com/kb/index.php/Display/279D85#Cookbook-SetupCIInfrastructure-CorporateArtifactsRecipe:SetupCIBuildforCorporateArtifacts
I Made sure the corporate distribution is unique since I have more that 1 Intershop installation. Otherwise the upload to Nexus(in my case) will still fail.
In the build.gradle of the corporate distibution folder added disableSCM = true in the scm.version section. It now looks like this:
scm {
version {
type = 'threeDigits'
increment = 'MAJOR'
patternDigits = 1
disableSCM = true
initialVersion = '2.0.0'
}
}
If this is not added I got a bad request httpstatus 400 from Nexus because it tried to upload it as a snapshot while the distribution repository is a release repository.
Another problem is the distributionURL in the project/gradle/wrapper/gradle-wrapper.properties
All Nexus repository URL's are build up with < repoBaseURL > + repositories/snapshots, but the distributionURL is missing the repositories part.
After applied those changes it worked for me.

Sudden syntax error after deployment

I have a working symfony project. I have it on a private bitbucked repository and locally the website works without an issue.
Today I tried to deploy the project onto an external server linuxpl.com.
Steps taken include:
Istalling composer
Adding the mysql database
Running git clone to get the data into a proper location
Running composer install on the folder to install everything and connect to the db
Cleared the cache
Set the project root as ....domain/project_name/web
However after completing all these steps, when running the website with regular server:run I'm getting this odd error:
Parse error: syntax error, unexpected '.' in /home/spirifer/domains/surowcewobiektywie.pl/konkurs/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1571
Not sure if this is of any importance but the mentioned code partion looks like this in my local files:
// Some objects throw exceptions when they have __call, and the method we try
// to call is not supported. If ignoreStrictCheck is true, we should return null.
try {
$ret = $object->$method(...$arguments);
} catch (BadMethodCallException $e) {
if ($call && ($ignoreStrictCheck || !$env->isStrictVariables())) {
return;
}
throw $e;
}
The local version does not differ from the one on the server.
My local machine has PHP 7.0.9 and the remove server has PHP 7.0.14
How could I fix this issue?
PHP 5.6 adds Variadic functions, with "...". However, Twig v1.x only required the use of PHP 5.2.7 or above.
If you didn't explicitly update to Twig 2.0, it's very possible you have used the 'death star' version constraint in the composer file - '*'. which allows uncontrolled version updates to the latest version. If this is the case, you will need to either update your version of PHP, or at least require just a previous version of Twig/twig, "^1.32" would be the latest in the version 1 series of Twig.

Artifactory has lost track of local artifacts

I'm using Artifactory OSS 4.1.0 and Java 1.8.0_51.
When I try to download one of my local artifacts from the Artifactory web interface, I get this:
{
"errors" : [ {
"status" : 500,
"message" : "Could not process download request: Binary provider has no content for 'bab1c4e18f6c5edfb65b2503a388dea2fed0deb8'"
} ]
}
But I found this file in my Artifactory data area: ./files/ba/bab1c4e18f6c5edfb65b2503a388dea2fed0deb8, and upon further inspection it is the WAR file I tried to download.
I've come across other people on the web with the same error message, but their issue was with caching external artifacts, and their workaround was to delete the cache.
Does anyone have an idea what's going on and how I can fix the problem? BTW, I did stop and restart our Artifactory server, but with no noticeable difference.
Artifactory doesn't store the binaries under ./files directory, but under $ARTIFACTORY_HOME/data/filestore.
It looks like you had a symbolic link from the files directory to the filestore directory and this link was deleted.

Resources