Two Artifacts, One Service

[sneakyaneurysm]

Hi all!

I was recently faced with an interesting situation, where a user wanted the ability to use two different artifact sources in the same Harness Service. Their use case was that they had a pre-prod artifact server and a production artifact server, but it was essentially the same artifact.

If you find yourself in the same scenario, follow these steps in Harness:

1. Connect both artifact servers to Harness (either through IAM or through our Artifact Server connections)
   
   
2. Create an Application in Harness
   
   
3. Create a Harness Service
   
   
4. Add the appropriate configurations in the Harness Service
   
   
5. Add a new Artifact Source in the Service and then connect it to the correct Address Server and artifact (make sure to make this appropriately)
   
   
   
6. Repeat the previous step, but make the appropriate changes
   
   
   
   
   
7. Create two Environments and Service Infrastructures/Definitions
   
   
   
   
   
   
   
   
   
   
   
8. Create the appropriate Workflow type and associate the Harness Service to the Workflow
   
   
9. Clicking Deploy will now give you two sub-options correlating to the different Artifact Sources you setup in steps 5 & 6. You can select the appropriate Source and Artifact Version for the deployment.
   
   
10. (Bonus) Templatize the Workflow to allow any Environment, Service, and Infrastructure.
    
    
11. (Bonus) Create a Trigger that allows you to deploy as needed
    
    
12. Sit back, relax, and deploy!

Hopefully this helps!

Please Like/Comment/Share!

[aochsner (Andrew Ochsner)]

I’m actually hitting a very similar issue and struggling a bit. I’ve got 3 artifact sources (representing dev/test/prod artifactory sources.

I have 1 templatized workflow to deploy any given service to any given environment

I’ve set up 1 parameterized trigger, but when I try to execute it I get the following error:
“Invalid Request: More than one artifact source defined for the service [XXX]. Please proide artifact source name”

Any ideas how to do that via the curl trigger?

I’m currently sending:
{ “application”: “XXX”,
“parameters”: {
“Environment”:“api-dev”,
“Service”: “service-api”,
“ServiceInfra_Kubernetes”: “service-dev-infra”},
“artifacts”: [{
“service”: “service-api”,
“buildNumber”:“2017.1.5”,
“name”: “dev”
}]}

[aochsner (Andrew Ochsner)]

Well through kind of random trial and error it seems adding "artifactSourceName": "<name of artifact source in the service>" appears to do the trick

[sneakyaneurysm]

Sorry for the delayed response, @aochsner. yes, that is the correct way to do it.

In those types of cases, you can create an explicit trigger (define every value) and then get the api call. That will allow you to get all payload info, then templatize the trigger.