I have OpenShift set up to build a ASP.NET Core application. I've succeeded in configuring OpenShift so it pulls in the latest source code. I see in the logs that it starts to build, but it immediately stops on the restore step.
OpenShift doesn't have access to our private NuGet feeds.
I know I can add credentials to the NuGet.config file, but that would mean committing sensitive information to the repository, which we don't want.
I've tried adding Input Secrets, as mentioned in the docs. I did this by creating a secret that contains the NuGet.config contents and adding the secret to my BuildConfig. I still get the same error (a HTTP 401).
Can I somehow tell OpenShift how to connect to the private NuGet feeds? Maybe using the secrets feature perhaps?
In the case of nuget configuration, you will need to specify where the NuGet.Config build input secret gets mounted into. This can be done by setting the destinationDir parameter to a valid configuration location.
As for being able to add the config file in your repository itself, you can do this by making use of environment variable references in the config, for example <add key="ClearTextPassword" value="%NUGET_REPO_PASSWORD%" />. The NUGET_REPO_PASSWORD environment variable can then be configured in your build configuration and value referenced from an OpenShift secret.
Hope this gets you going. If all else fails, you can definitely override the s2i assemble script with your own by adding an executable script at .s2i/bin/assemble of your project repository.
Related
I have a NextJS project I want to deploy to Vercel. The server needs a config file which is a typescript file containing an object, and is ignored from version control. Obviously when Vercel clones my repo it doesn't get the config file. Is there any way to sideload this config file into Vercel or do I need to fork my own repo privately so I can include the config file?
I've done some research and the only faster way I found is to push directly to Vercel using the cmd/cli.
Here's the doc: https://vercel.com/docs/cli
Another way could be to create two repositories, one private where is your Vercel project linked, and another public without your config file (as you said).
It seems my team mates have turned off their nuget server and gone on holidays.
I need a temporary work around so that my Azure Dev Ops build does not fail when restoring the nuget packages.
I have a local copy of the package at
C:\Users\kirst.nuget\packages\mypackagetemp
Which I want to publish to a temporary feed.
I read the instructions on publishing a package from the command line but am confused about step 6
Surely I dont need to set up the Project and restore packages as I already have the .nupkg
I tried the command
c:\nuget\nuget.exe push -Source "TempFeed" -ApiKey az mypackagetemp.nupkg
but got an error
unable to load the service index for source
https://pkgs.dev.azure.com/mycompany/myproject/_packageing/TempFeed/nuget/v3/index.json
When I repeat the command I get a request for credentials
When I put in the credentials I connect to Azure Dev Ops with they do not work.
[Update]
I was prompted for credentials.. reading up on it... so confusing.
[Update]
I upgraded nuget.exe from 5.1.0.6013 to the latest version 5.4.0.6315 This time I got a UI to log in and the message
Your package was pushed
However when the devops pipeline build runs I het a message
unable to load the service index for source
https://pkgs.dev.azure.com/mycompany/myproject/_packageing/TempFeed/nuget/v3/index.json
I guess I need to create an index.json file somehow.
My project is using a mynuget.config that has the following in the packagesources
<add key="TempPackage" value="https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget" />
[Update]
I changed mynuget.config to have
<add key="TempPackage" value="https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/v3/index.json" />
Now the dev ops build shows the message
Failed to retrieve information about 'Serilog.Enrichers.Thread'
from remote source
'https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/FindPackagesById()?id="Serilog.Enrichers.Thread'',
response status code does not indicate success: 404 (Not Found).)
My solution does use Serilog. I don't think the 3rd party package uses it.
[Update]
The next time I built I got a different error looking for WindowsAzure.Storage
I seem to get a different file causing the error each time I build the pipeline.
My project artifacts does have 2 feeds. The needed files are in the unselected feed.
[Update]
I tried editing mynuget.config to use index.json however I get a build error
The nuget command failed with exit code(1) and error(Unable to load
the service index for source
https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/v3/index.json.
Response status code does not indicate success: 404 (Not Found - The
feed with ID 'MyFeed' doesn't exist
[Update]
Because the new feed was project based I edited mynuget.config to have
<add key="TempPackage" value="https://pkgs.dev.azure.com/mycompany/myproject/_packaging/myfeed/nuget/v3/index.json" />
Now it works!
In Azure Devops web portal, for your current project, go Artifacts tab and make sure your packages like mypackagetemp.nupkg are available there.
For me, I have custom LibraryCore.nupkg pushed there. Now let's click the Connect to feed settings, choose nuget.exe and you can see:
Copy exactly same content to your own mynuget.config file. Then your build pipeline can access your published mypackagetemp.nupkg.
Failed to retrieve information about 'Serilog.Enrichers.Thread' from
remote source
'https://pkgs.dev.azure.com/mycompany/_packaging/myfeed/nuget/FindPackagesById()?id="Serilog.Enrichers.Thread'',
response status code does not indicate success: 404 (Not Found).)
The next time I built I got a different error looking for
WindowsAzure.Storage
These packages(Serilog.Enrichers.Thread,WindowsAzure.Storage and ...) are all available in nuget.org, so you should also make sure you've add nuget.org as package source in your config file:
In addition:
According to your description, you only need to use your custom devops feed and other packages from nuget.org, apart from using your mynuget.config, you could configure your nuget restore task like this:
Choose devops feed directly(second red line) by Feeds I select here instead of Feeds in my Nuget.config. And check the Use packages from nuget.org checkbox. Then you can access the packages in custom feed and nuget.org during build.
Context
creating an sdk that uses AWS DynamoDb in .NET 4.7.2. In my test project, I have an app.config file that references a secrets.confg file that stores my AWS keys. The secrets config is not included in any commits, for obvious reasons. However, I've uploaded secrets.config to my Library in DevOps as a "secure file". I also have a "download config file" task in the build process that downloads secrets.config to Agent.Temporary
Issue
I don't understand how modify the build process to "pick up" my secrets.config file so that when running my tests, the test project's app.config file knows where to look for secrets.config.
I've looked over a lot of documentation and I can't find exactly how to do this.
I figured this out by using a couple of tasks within the Build Configuration.
I added a Download Secure File task to download my app.config from the Library. And then setup a Copy Files task for each project that needed the app.config.
Each task set:
Source Folder to "$(Agent.TempDirectory)"
Contents to "app.config"
Target folder to "$(Build.SourcesDirectory)\Project.Tests\"
In the end, it wasn't any more complicated than that. I hope this will help others...
I have a project that uses Entity Framework 6.x, ASP .NET WebApi 5.x. Data Access is in a secondary project inside the solution. I want to use VSTS (aka Visual Studio Online) to build and release it as a website to environments for integration/dev, qa, stage, and production. There are some great videos on Channel 9 that deal with the generic high-level description. (for example https://channel9.msdn.com/Series/DevOps-Release-Management and https://channel9.msdn.com/Series/DevOps-Fundamentals/Infrastructure-as-Code) There are all kinds of articles and videos about how to do migrations from inside Visual Studio including generating scripts.
Searching around the web I don't even find any older resources or concrete examples of continuous deployment with code first migrations. There must be examples and best practices for methods other than auto-migrations or SQL scripts.
I have configured a Web Deployment Package publish profile. I use it via the PublishProfile msbuild.exe directive. The package is added to the artifacts and then deployed by the Azure Web App Deployment task in each Release environment. However once this package is built, I don't know of a way of changing the connection string in the build package for each time it is released to an environment.
There is probably something I am overlooking, but how should environment specific migrations be done with via VSTS Release?
For Code First Migration, you can "Write App_Start code to run Migrations" or "Write Web.config transforms to configure the MigrateDatabaseToLatestVersion initializer to run", refer to this article for details: http://blogs.msdn.com/b/webdev/archive/2014/04/09/ef-code-first-migrations-deployment-to-an-azure-cloud-service.aspx
For the connection string transformation with profile, you need to add a web.config file for the publish profile and then enter the connection string in this web.config. Refer to this link for details: http://awaitwisdom.com/publish-profile-config-transform/
I hate to answer my own questions here but, ultimately my research took me to the conclusion I am posting at length here. In sort, Web.config and Parameters.xml require some custom scripting that will require you to maintain your own deployment automation. These routes will still require you to additionally create your resource groups or manage them manually.
To avoid these complications and cobbling tools and scripts together, the whole operation can be achieved with two JSON files. These JSON deployment templates allow you to create or update your resource group when your deployment runs. They also allow you to automate setting appsettings and connectionstrings that overwrite your Web.config values in the same manner as you can through the Azure Portal.
the steps: (1) Add the two JSON files to the project setting the name of you connection string on line 88 (2) Add a Azure Resource Group Deployment task to the Release environment. (3) Set Template (WebSite.json) and Template Parameters (WebSite.parameters.json) paths in the task. (4) Set Override Template parameters to -hostingPlanName "myHostingPlan" -webSiteName "myWebsiteName" -connectionString "the-actual-connection-string" (5) make sure you are using the same website name in your Azure App Deployment task.
This does depend on having your code first migrations run via App_Start or something similar. I took the first part of #Eddie's suggestion since App_Start is easy to deal with and doesn't seem to run too often.
As a bonus you can add environment variables for any of this configuration so you can clone the environment and then just change the variables. This ultimately makes your application or api connection string a Release variable.
We have a couple of cloud services and do a Continuous Delivery to a test environment via Team Build.
For the production environment, we have our own deployment powershell script. This script needs a .cspkg file for deployment.
My problem is now that I haven't found a way to let team build just create a .cspkg file but not to publish it to Azure.
I've used the AzureContinousDeployment.11.xaml template and it insists on publishing the package.
I've tried to set the "Deployment Settings Name" to an empty string. The build runs without errors, but that way, no package is created.
Is there a way to stop it somewhere in between?
Maybe something I could change in the .azurePubxml file to achieve that?
Environment: VS2012, Team Foundation Service (visualstudio.com)...
On the Process tab of the edit definition:
If you clear out the Deployment Settings Name and all the values under Publishing - Azure Cloud Service and Publishing - Azure Website (except you can leave True for the Allow Upgrade) the building template won't know where to publish the project.
Also on the Build Defaults tab of the edit definition:
Select the "Copy build output to the following Source Control folder (this folder will be created if it does not exist):"
Add some name and path like: "$/your cloud service/drops"
That will cause all your builds to be moved to the drops folder after a successful build. In those drops folders, there will be a app.publish directory that will have your *.cspkg and *csfg files.
I have my custom build template xaml invoke the MSBuild task (Microsoft.TeamFoundation.Build.Workflow.Activities.MSBuild) on the Azure project (.ccproj file) with the "Publish" target.
(Despite having the same name as the UI command that pushes the package to Azure, the "Publish" target just means "generate the package without pushing it anywhere".)