Open o-o00o-o opened 5 years ago
Well I thought I might be able to help isolate this by renaming the ispac and publish.json to be unique for each branch but this was not as easy as I had hoped. I got the warning
Test-ProjectParamsMatch : Ispac File and (VegaDW.Etl_33867) and project name in json file (VegaDW.Etl) do not match. Mismatch will cause deployment to fail...
So I guess we either need to do this more deeply and allow a different project name for each feature (right now it is just the folder that is different), or the issue to be identified in AssistDeploy
Hello!
Are the deployments running simultaneously on the agent? I guess the clue is in the issue name but just want to confirm.
Oh! And what tool are you using for CICD? I am wondering if environment variables are being set as the location by the tool and values are being overwritten.
We are using Azure Devops as CICD tool. We have 5 agents installed on the same machine running as the same user. Each one has its own isolated folder space and has its own windows service
Interesting idea about environment variables. The person that implemented this I think tried to avoid the general use of the variables to set the SSIS environment variables. He wrote a Merge-SsisProfile.ps1 that does this directly in the json file.
So it looks like this
Then the merge sets the ssisEnvironmentVariables itself, first but creating a hashtable with all the variables in
Then adding to the json
Apart from this it is all your standard stuff I think
Are there any of the other environment variables global for the user?
Since we increased the number of build agents on our development machine to more than one, we have been seeing an intermittent issue where the wrong package is being deployed. We are using 2.0.5766 from Nuget
We run multiple feature branches and each feature will have its own set of ssis packages (and therefore ispac/json file). all the ispac packages have the same filename
We can see that the ispac file and the datasource are correct going in but then when our tests run it shows a problem with code that we had already fixed.
Is there any shared area/files etc that things are being built that limits AssistDeploys to be single-threaded?