I created a mono application on OpenShift using the community cartridge here.
Now, I'm reading about how to set up continuous builds via jenkins here.
The default mono application doesn't seem to come with any of the necessary scripts for building, restoring NuGet packages, etc. Instead, the git repo seems to have the DLL binaries in it, which doesn't seem sustainable.
What's the best approach for deploying mono on open shift?
I will refine this answer when/if I get it working...
Did you start by clicking the "Continuous Integration - Enable Jenkins" link below your cartridge on your OpenShift Applications page?
Once I did this, my git push output changed from:
remote: CLIENT_MESSAGE: Stopping Apache+mod_mono HTTPD server
remote: Waiting for stop to finish
remote: Waiting for stop to finish
remote: Stopping Postgres cartridge
remote: Building git ref 'master', commit 8da79f2
remote: Preparing build for deployment
remote: Deployment id is 05e8d1d8
remote: Activating deployment
remote: Starting Postgres cartridge
remote: Postgres started
remote: CLIENT_MESSAGE: Starting Apache+mod_mono HTTPD server
remote: -------------------------
remote: Git Post-Receive Result: success
remote: Activation status: success
remote: Deployment completed with status: success
To:
remote: Executing Jenkins build.
remote:
remote: You can track your build at https://jenkins-[you].rhcloud.com/job/mono-build
remote:
remote: Waiting for build to schedule...........Done
remote: Waiting for job to complete...............Done
remote: SUCCESS
remote: New build has been deployed.
remote: -------------------------
remote: Git Post-Receive Result: success
remote: Deployment completed with status: success
But if I remove the bin directory from my source code, then the web site no longer works, even though the build "succeeds." So clearly it is only just blindly copying the files out of git.
So next I did a Update-Package -reinstall -ProjectName OpenShift in the Package Manager console, then right-clicked on the solution and chose "Enable NuGet package restore," and committed/pushed those changes.
In the Jeninks manager I went to Configure the build and added xbuild OpenShift.sln after the gear build line in the "Execute shell" area.
Now it actually tries to do a real build, which fails with the error:
+ xbuild OpenShift.sln
XBuild Engine Version 3.0.7.0
Mono, Version 3.0.7.0
Copyright (C) Marek Sieradzki 2005-2008, Novell 2008-2011.
Build started 01/13/2015 20:56:29.
__________________________________________________
/var/lib/openshift/[my ID]/app-root/runtime/repo/OpenShift.sln: warning : /var/lib/openshift/[my ID]/app-root/runtime/repo/OpenShift.csproj: /var/lib/openshift/[my ID]/mono/mono/lib/mono/xbuild/Microsoft/VisualStudio/v10.0/WebApplications/Microsoft.WebApplication.targets: Project file could not be imported, it was being imported by /var/lib/openshift/[my ID]/app-root/runtime/repo/OpenShift.csproj: Access to the path "/var" is denied.
Project "/var/lib/openshift/[my ID]/app-root/runtime/repo/OpenShift.sln" (default target(s)):
Target ValidateSolutionConfiguration:
Building solution configuration "Debug|Any CPU".
Target Build:
/var/lib/openshift/[my ID]/app-root/runtime/repo/OpenShift.csproj: error : /var/lib/openshift/[my ID]/app-root/runtime/repo/OpenShift.csproj: /var/lib/openshift/[my ID]/mono/mono/lib/mono/xbuild/Microsoft/VisualStudio/v10.0/WebApplications/Microsoft.WebApplication.targets: Project file could not be imported, it was being imported by /var/lib/openshift/[my ID]/app-root/runtime/repo/OpenShift.csproj: Access to the path "/var" is denied.
Task "MSBuild" execution -- FAILED
Done building target "Build" in project "/var/lib/openshift/[my ID]/app-root/runtime/repo/OpenShift.sln".-- FAILED
Done building project "/var/lib/openshift/[my ID]/app-root/runtime/repo/OpenShift.sln".-- FAILED
Build FAILED.
Looks like it might be this problem so I made the following manual diff to OpenShift.csproj:
- <Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
- <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
+ <Import Project="$(SolutionDir)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" />
and copied from Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications into the above path in my local project.
After committing/pushing that, now I get this new build error:
Project "/var/lib/openshift/[my id]/app-root/runtime/repo/OpenShift.sln" (default target(s)):
Target ValidateSolutionConfiguration:
Building solution configuration "Debug|Any CPU".
Target Build:
Project "/var/lib/openshift/54b5dc8efcf933bb7300001f/app-root/runtime/repo/OpenShift.csproj" (default target(s)):
Target RestorePackages:
Executing: mono --runtime=v4.0.30319 "/var/lib/openshift/[my id]/app-root/runtime/repo/.nuget/NuGet.exe" install "/var/lib/openshift/[my id]/app-root/runtime/repo/packages.config" -source "" -RequireConsent -solutionDir "/var/lib/openshift/[my id]/app-root/runtime/repo/"
Cannot open assembly '/var/lib/openshift/[my id]/app-root/runtime/repo/.nuget/NuGet.exe': File does not contain a valid CIL image.
Looks like there's a problem running NuGet.exe - Might be this
Related
We run automated code-quality scans in SonarQube that are triggered by pipelines in Azure DevOps:
# retrieve and build code, run unit tests etc.
- task: SonarQubePrepare#4
displayName: 'Prepare SonarQube Scan'
inputs:
SonarQube: 'SonarQube DevOps Connection'
scannerMode: 'CLI'
configMode: 'file'
- task: SonarQubeAnalyze#4
displayName: 'Run SonarQube Scan'
- task: SonarQubePublish#4
displayName: 'Publish SonarQube Scan Report'
inputs:
pollingTimeoutSec: '300'
About a week ago, the main analysis task ('Run SonarQube Scan') began failing for all pipelines with the following error:
...
##[error]ERROR: Error during SonarQube Scanner execution
ERROR: Error during SonarQube Scanner execution
##[error]java.lang.IllegalStateException: Unable to load properties from file /home/vsts/work/1/s/.scannerwork/report-task.txt
java.lang.IllegalStateException: Unable to load properties from file /home/vsts/work/1/s/.scannerwork/report-task.txt
...
##[error]Caused by: java.io.FileNotFoundException: /home/vsts/work/1/s/.scannerwork/report-task.txt (No such file or directory)
Caused by: java.io.FileNotFoundException: /home/vsts/work/1/s/.scannerwork/report-task.txt (No such file or directory)
...
We have made no changes to our pipelines, so I am mystified as to what has caused this change.
We are using SonarQube Enterprise EditionVersion 7.9.1 (build 27448) (on-premise installation) and version 4.9.0 of the SonarQube extension for Azure DevOps (published by SonarSource).
UPDATE 25/3/20 (thanks to patricklu-msft):
We are using a Microsoft-hosted build agent with an ubuntu-16.04 image. Running the pipeline in debug mode reveals the following:
2020-03-25T14:25:00.3694399Z 14:25:00.369 DEBUG: Report metadata written to /home/vsts/work/_temp/sonar/20200325.2/eec0f38a-913b-3db3-e1b2-71091ea5f860/report-task.txt
So it appears that the report metadata are being written to /home/vsts/work/_temp/sonar/20200325.2/eec0f38a-913b-3db3-e1b2-71091ea5f860/report-task.txt but SonarQube subsequently looks for them in /home/vsts/work/1/s/.scannerwork/report-task.txt. It looks like there is a mv operation missing somewhere ...
Not sure if it's a SonarQube task side related issue.
According to this link here:
The new version (4.7.x) is looking here:
##[debug]adjustedPattern: 'C:\AzureDevops\Agent2-GCS-Docker\_work\_temp\sonar\199416\**\report-task.txt’
Looks like it's supported to look the report-task.txt in temp folder with new version.
Try to roll back your task version and check if this do the trick.
Closer inspection of the Azure pipelines logs revealed these two entries that weren't there before:
2020-03-26T15:26:44.0989881Z INFO: Executing post-job 'Forbidden Configuration Breaker'
2020-03-26T15:26:44.0990841Z INFO: Executing post-job 'Quality Gate Breaker'
Someone installed the Sonar Build-Breaker Plug-in a week ago without telling us, and none of us have correctly configured it in our pipelines yet. Setting it to skip the quality gate check (sonar.buildbreaker.skip=true) effectively by-passes it (although those two log entries still appear) and the pipelines run successfully once more.
Update 24/04/2020: I have now upgraded the Build Breaker plug-in to v2.3.1 (build 347) and that seems to have fixed the issue.
All,
I set up MS Build TASK on VSTS that would work on a Git Repo containing a SSDT project.
When I run this task, I get the below error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(283,5): Error MSB3202: The project file "..\Master\Master.sqlproj" was not found.
Process 'msbuild.exe' exited with code '1'.
ANy idea what this error could be?
Gopi
I'm using a batch file to load a workspace repository and accept change sets.
The files in the repository have Eclipse projects.
When I accept a change set, the SCM automatically creates the projects in .metadata:
Windows:
C:\Users\[user_name]\AppData\Local\jazz-scm\scratch\0\.metadata\.plugins\org.eclipse.core.resources
If I accept another change set with changes in Eclipse projects, the SCM tries to create the project in .metadata and throws this error in the log:
com.ibm.team.filesystem.client.FileSystemStatusException: Status ERROR: com.ibm.team.filesystem.client code=0 There were issues encountered during the updating of the sandbox. null children=[Status ERROR: com.ibm.team.filesystem.client code=0 Unable to open project at [path_of_file]/.project, project with name [project_name] already exists null Status ERROR: com.ibm.team.filesystem.client code=0 Unable to open project at [path_of_file]/.project, project with name [project_name] already exists null]
How do I prevent the SCM CLI accept command from generating projects in .metadata?
SCM CLI version:
Build Id: RTC-I20141031-0926
com.ibm.team.filesystem.cli.client, version 3.2.400.v20141016_0123
com.ibm.team.filesystem.cli.tools, version 3.1.800.v20140620_0123
com.ibm.team.filesystem.cli.core, version 3.2.400.v20141011_0139
com.ibm.team.rtc.cli.infrastructure, version 3.1.800.v20140619_0246
For awhile in my Team City build, I am unable to publish my source NuGet packages to symbolsource.org as it responds with 500 Internal Server Error.
[16:02:36][push] Pushing NCode.Composition.DisposableParts 1.0.1 to the symbol server (http://nuget.gw.symbolsource.org/Public/NuGet)...
[16:04:18][push] Failed to process request. 'Internal Server Error'.
[16:04:18][push] The remote server returned an error: (500) Internal Server Error..
[16:04:18][push] Process exited with code 1
I am able to publish my normal packages to NuGet.org just fine. I believe that I have properly configured everything as documented by symbol source.
https://www.symbolsource.org/MyGet/Wiki/Publishing
http://www.symbolsource.org/Public/Metadata/NuGet
https://www.symbolsource.org/Public/Account/Register
Here is my Build Step configuration for NuGet Publish:
Runner Type: NuGet Publish
NuGet.exe: Default 2.8.6
Packages: *.nupkg
API Key: (my personal API key from NuGet.org)
Package Source: (blank)
In my build output directory and artifacts recognized by TeamCity, I do have both of my packages in there:
NCode.Composition.DisposableParts.1.0.1.nupkg
NCode.Composition.DisposableParts.1.0.1.symbols.nupkg
Any assistance would be appreciated!
I think that the problem is with two packages with the same name. Did you try a workaround with another build configuration and snapshot dependency?
I'm using another build configuration with snapshot dependency to build which produces *.nupkg and *.symbol.nupkg. Artifact dependency is set to:
-:*.nupkg => <replace with location>
+:*.symbol.nupkg
The build configuration only publishes *.symbol.nupkg to symbolsource.org.
I'm trying to release new version on a test projet but my artifact is not recognised.
Discovering tests...OK
Deploying using GitHub provider
Creating "a2" release for repository "Phonations/TravisTest" tag "a2" commit "44d044aa7708508f016dfef67fbdd82f08642f8d"...OK
No artifacts were published. Make sure you have specified correct artifacts filter.
Build success
(full output available here)
I checked the artifact artifact.txt is present as you can see when performing the dir command in the build output.
It is specified here
You should setup artifacts packaging in appveyor.yml. For that file in your project this would be:
artifacts:
- path: artifact.txt