I am looking for a solution to what appears a simple problem but is proving quite difficult to crack.
I have a number of artifacts (predominantly jar files) downloaded from Artifactory and which I am looking to bulk upload to our new repository, DevOps Azure Package Manager.
I am open to any solution, ideally one that can be run from the command line or set up as an Azure DevOps (VSTS) build/release pipeline Task. The key requirement though is that it should have the capability to perform a bulk upload, not singularly. Would appreciate any positive ideas or suggestions on how to achieve this.
Microsoft’s Package Manager looks as norml Maven repository so You can use any method thats supports publishing artifacts to remote repository.
Here is sample with gradle https://dzone.com/articles/how-to-upload-a-list-of-jars-into-nexus-or-artifac
Please follow standard procedure to generate credentials for Maven/Gradle to be able to publish one artifact, then adjust sample gradle script to Your needs
Related
The distribution url in my gradle-wrapper.properties is pointing at
https://services.gradle.org/distributions/gradle-7.5.1-bin.zip
That is, its pointing towards the internet. Is it possible to use the Azure devops artifacts url instead, and let it cache gradle distributions for future proofing?
We (Azure Artifacts) don't have anything that would handle that directly. You might be able to script something up to store the files using Universal Packages, but you'd have to handle all the details yourself.
One of our development teams have recently migrated their Maven project files from another version control system to Azure DevOps. However, a major caveat is that these Maven projects were created with no POM files (I have no idea why).
The project team have in any case managed to move all of their Maven packages into Azure Artifacts. When a release pipeline job is then run, it is then expected to retrieve the desired artifacts (*.war files) from Azure Artifacts, download to the agent's artifacts directory and subsequently deploy to the target server. The pipeline itself is completed successfully (all tasks set to green status), however when we review the output log, we discover that the artifacts were never downloaded and instead, the download task returns an "UnhandledPromiserejectionWarning". Any idea why this is happening?
So far, we've tried using CURL as an alternative to download the artifacts, but all has been in vain. Naturally, we've also tried and failed with the Azure Artifacts' dedicated "Download Package" pipeline task, but are willing to try an alternative solution, if anyone has some kind suggestions. Been wondering something like Powershell (or other script) can for instance be used to download the desired package files.
I must also mention that the CURL option only appears to fail over a failed OAuth authentication. Any advice on that front will also be helpful, as it is probably our quickest route to a workaround.
I had a similar issue, it turns out the problem was just the capital case.
The DownloadPackage task was trying to download 0.0.30-SNAPSHOT, but instead you can only download the package as 0.0.30-snapshot, as it states on the microsoft official docs.
In order to fix it, I had to install an external plugin, then add an additional task before download, that task was converting the name to lower case.
I was using the classical release pipeline, btw.
So I'm trying to do a proof of concept with the Azure DevOps stack and a project Java Maven project I usually build with Jenkins and host with Heroku. Initially I was trying to setup a release pipeline straight from the build pipeline WAR file but since it couldn't find it I said to myself "well, if you publish to artifacts it should be straighforward" so I did.
Build is publishing a maven artifact to Azure Artifacts
No issues here as far as I'm concerned. I didn't mess with permissions, but I did notice that under Feed Settings, I cannot selected (it's greyed out) "Allow builds and releases". But the Project Collection Build Services is set as a contributor.
Configuring the artifact in the release
So here is the first potential issue. The feed shows up in the dropdown but the artifact doesn't. There's only one artifact on the feed so I find this strange:
So I'm asked to entered it manually and this is where things start to get tricky. To me the id of the artifact should be the maven coordinates com.acme.demo:reading-time-app. If I enter that I can proceed, but there's no confirmation that's the right ID:
Creating and triggering the release
So as I create a new release it asks me for the version number and again the dropdown doesn't come up. So I write in version 1.1 which you can confirm from the first screenshot it exists:
I trigger the release and I get the following error during the Download Artifact phase:
2019-01-19T17:11:46.7642756Z ##[section]Starting: Download artifact - _com.acme.demoreading-time-app (Azure Artifacts)
2019-01-19T17:11:46.7895376Z ==============================================================================
2019-01-19T17:11:46.7895486Z Task : Download Package
2019-01-19T17:11:46.7895573Z Description : Download a package from a Package Management feed in Azure Artifacts or TFS.
Requires the Package Management extension.
2019-01-19T17:11:46.7895642Z Version : 0.1.17
2019-01-19T17:11:46.7895704Z Author : ms-vscs-rm
2019-01-19T17:11:46.7895757Z Help : Needs Package Management extension to be installed
2019-01-19T17:11:46.7895859Z ==============================================================================
2019-01-19T17:11:48.2563329Z SYSTEMVSSCONNECTION exists true
2019-01-19T17:11:48.2619024Z ##[error]Failed to get package metadata with error Error: Invalid Resource
2019-01-19T17:11:48.9982590Z ##[section]Finishing: Download artifact - _com.acme.demoreading-time-app (Azure Artifacts)
I'm losing my mind here. I'm thinking this should be pretty straighforward but I'm not even at the stage to debug any issues with the deployment into the Azure App Service yet. Any help is deeply appreciated.
Thank you in advance!
Sorry for the confusion here - currently, the "Azure Artifacts" artifact type only supports NuGet packages. We should have a string change out in the current deployment making that clearer. We're also working to expand it to support all the other types (Maven, npm, Python, and Universal); that should be available around end of February.
The issue is known to many maven based projects using feature branches. In maven, there is no concept of a branch. Now in a git-flow environment there are basically 2 ways to deal with the build artifacts:
modify the version number to something like "featureX-1.0.0-SNAPSHOT".
Separate the SNAPSHOT repositories to get an isolated build and dev environment. Use a maven extension to determine the branch and select the proper repositories early in the process.
Variants of the two seem to exist, but both have its drawbacks. We would like to go in our team to option 2 and share the pipelines to publish maven artifacts to separate package feeds.
Is there any way to automate the creation of package feeds on the event of a git branch creation?
I'm trying to replicate a Jenkins production need in my lab, and it involves fetching/pulling files from Github & Nexus 2, building with ant/gradle, then publishing to Nexus. The Github part is working fine in my Jenkins pipeline, but I'm having some issues with the syntax/reqs for Nexus. I installed Nexus OSS in my lab to duplicate Nexus 2's functionality. I am able to upload files manually to the repo using curl, and I'm sure I can use it to download as well. This doesn't seem like the best or most efficient option however, if there will be multiple files.
I keep seeing references to Maven/pom.xml on all my searches for this topic, but I can't find a good primer on how to use them in this context. Would a pom.xml file be the best option for
this Jenkins/Nexus configuration and the requirements? Also, how close are Nexus 2/3 in functionality to Nexus OSS? Will I be able to port over the code for use with nexus 2 fairly easily?