Can grunt-regard be configured to run a subset of watch tasks instead of all tasks? - watch

I am using gruntjs to build my js application. My grunt file is setup to run two separate builds where 80% of the code is the same for both and depending on the build we include additional files and exclude some files.
I have grunt setup to run the two different builds correctly except I cant tell grunt-regard to run multiple times.
regarde:
coffeeScripts:
files: ['app/scripts/kiosk/*.coffee', 'app/scripts/*.coffee'],
tasks: ['coffee:compileKiosk', 'livereload']
stylusScripts:
files: ['app/css/kiosk/*.styl', 'app/css/*.styl'],
tasks: ['stylus:compileKiosk', 'livereload']
coffeeScriptsWeb:
files: ['app/scripts/web/*.coffee', app/scripts/*.coffee],
tasks: ['coffee:compileWeb', 'livereload']
stylusScriptsWeb:
files: ['app/css/web/*.styl', 'app/css/*.styl],
tasks: ['stylus:compileWeb', 'livereload']
I want to be able to do something similar to the tasks below, but only the first regarde task runs and the second is ignored.
grunt.registerTask 'watchKiosk', ['livereload-start', 'regarde:coffeeScripts', 'regarde:stylusScripts']
grunt.registerTask 'watchWeb', ['livereload-start', 'regarde:coffeeScriptsWeb', 'regarde:stylusScriptsWeb']
My folder structure looks like
app (application root)
scripts (contains common script files)
kiosk (contains script files only for kiosk build)
web (contains script files only for web build)
css (contains common css files)
kiosk (contains css files only for kiosk build)
web (contains css files only for web build)
Ideally when working with the web build I do not want to recompile all the kiosk files and web files when a file changes.
Is there any way to setup grunt to have multiple regarde tasks defined and run the specific task I want for the build I am working on?
If I run these grunt tasks the watch works but will rebuild files that are not part of the specific build I am working with
grunt.registerTask 'watchKiosk', ['livereload-start', 'regarde']
grunt.registerTask 'watchWeb', ['livereload-start', 'regarde']

Thanks to asgoth for his link, from the linked answer I was able to figure out a way to do this. This might not be the best way but it works.
I added two different configurations for my regarde task (one for the kiosk build and one for the web build) to the grunt file:
regardeKiosk:
coffeeScripts:
files: ['app/scripts/kiosk/*.coffee', 'app/scripts/*.coffee'],
tasks: ['coffee:compileKiosk', 'livereload']
stylusScripts:
files: ['app/css/kiosk/*.styl', 'app/css/*.styl'],
tasks: ['stylus:compileKiosk', 'livereload']
and
regardeWeb:
coffeeScriptsWeb:
files: ['app/scripts/web/*.coffee', app/scripts/*.coffee],
tasks: ['coffee:compileWeb', 'livereload']
stylusScriptsWeb:
files: ['app/css/web/*.styl', 'app/css/*.styl],
tasks: ['stylus:compileWeb', 'livereload']
Then I created a multi task that picks the correct configuration and updates the regarde config before starting the regard task.
#startWatch config
startWatch:
web: 'Web'
kiosk: 'Kiosk'
grunt.registerMultiTask 'startWatch', 'refreshing the changed file(s)', () ->
#read regarde config and regarde template config. #data comes from startWatch config
regardeConfig = grunt.config('regarde')
correctConfig = grunt.config('regarde' + #data)
#replace regarde config with the correct config
grunt.config('regarde', correctConfig)
#run regarde task
grunt.task.run('regarde')
Then I am able to define my two grunt tasks and pick which regard task to run based on the build
grunt.registerTask 'watchKiosk', ['livereload-start', 'startWatch:kiosk']
grunt.registerTask 'watchWeb', ['livereload-start', 'startWatch:web']

Related

How to exclude artifact files after web deployment?

We have a build/release pipeline that is finally working correctly, but the developer asked that we exclude the stage config files (Web.Dev.config, Web.Test.config, Web.Prod.config) as well as the artifact archive itself from the site/wwwroot.
As you can see, every time we deployed, these zip files have been getting stored in the site root as well. They aren't harmful but it doesn't look good:
This is the Release App Service Web Deploy YAML:
steps:
- task: AzureRmWebAppDeployment#4
displayName: 'Azure App Service Deploy: project-123'
inputs:
azureSubscription: 'Azure Dev Service Connection'
WebAppName: 'project-123'
packageForLinux: '$(System.DefaultWorkingDirectory)/Project123 Dev Build Artifact/Release'
enableCustomDeployment: true
enableXmlTransform: true
How do we exclude those files after successful deployment?
Kudu dir structure:
Building on #theWinterCoder answer, Unfortunately, there doesn’t appear to be a way to honor the MSDeploySkipRules defined in the csproj file. Instead, files and folders can be skipped by defining the AdditionalArguments parameter of the Azure App Service Deploy (AzureRmWebAppDeployment) task.
Since there doesn’t appear to be any official documentation for the -skip rules, and the MSDeploy.exe documentation that Azure Pipelines references is out-of-date, in 2012, richard-szalay wrote a useful article, “Demystifying MSDeploy skip rules”, which provides a lot of details for anyone requiring additional control.
Brief Explanation:
The dirPath argument represents the Web Deploy Provider to skip a directory whilst the filePath argument is used to skip an individual file.
The dirPath starts at wwwroot.
For ASP.NET Core applications, there’s another wwwroot under wwwroot; as such, the absolutePath in that case would look like this: absolutePath=wwwroot\\somefoldername which would map to D:\home\site\wwwroot\wwwroot\somefoldername
Solution:
Therefore, since I’m skipping files, i set the web deploy provider to filePath, and since we’re not using .NET Core, we set absolutePath to Web.Dev.config. That would map to D:\home\site\wwwroot\Web.Dev.config.
The same thing applies for the zip artifact, however, if we don’t prepend \\ before the wildcard it will fail with following error:
Error: Error: The regular expression '.zip’ is invalid. Error: parsing ".zip" - Quantifier {x,y} following nothing. Error count: 1.
-skip:objectName=filePath,absolutePath=Web.Dev.config
-skip:objectName=filePath,absolutePath=Web.Prod.config
-skip:objectName=filePath,absolutePath=Web.Test.config
-skip:objectName=filePath,absolutePath=\\*.zip
or with regular expression:
-skip:objectName=filePath,absolutePath="Web.Dev.config|Web.Prod.config|Web.Test.config|\\*.zip"
Thats it 😃
You can add an additional arguments line to the yml that will tell it to skip certain files. It will look something like this:
AdditionalArguments: '-skip:objectName=dirPath,absolutePath=wwwroot\\Uploads'
More details can be found in this thread

Is there a way to pipe the smoke test output outside the agent?

I have a release pipeline with a QA/Smoke Test stage, that generates XML files containing test results.
If I run this manually on my machine, obviously I have access to the XML files and I can see the details but on the agent I cannot since we don't have access to those Microsoft hosted agents to view the files.
Is there a way to pipe the files "out" in the task for viewing? maybe there's a third marketplace task that can achieve that?
Here's the deployment result:
2021-06-06T23:34:19.1260519Z Results File: D:\a\r1\a\qa-automation\TestResults\CurrentReport\Logs\junit.xml
2021-06-06T23:34:19.2448029Z Results File: D:\a\r1\a\qa-automation\TestResults\.\CurrentReport\Logs\detailedLogs.xml
2021-06-06T23:34:19.2533810Z
2021-06-06T23:34:19.2596243Z Failed! - Failed: 22, Passed: 2, Skipped: 0, Total: 24, Duration: 52 m 11 s - EED.dll (netcoreapp3.1)
Here's the stage YAML:
steps:
- script: |
git clone https://.../qa-automation.git -b master
cd qa-automation
testrun.bat --cat "EDSmoke" --env dev
displayName: 'Clone qa-automation repo'
Is there a way to pipe the files "out" in the task for viewing? maybe there's a 3rd marketplace task that can achieve that?
You can try with following task:
Write-host "##vso[task.uploadfile]<PathOfTheFiles>\<filename>"
Like:
Write-host "##vso[task.uploadfile]$(System.DefaultWorkingDirectory)\qa-automation\TestResults\CurrentReport\Logs\junit.xml"
View and download attachments associated with releases
Would you like to upload additional logs or diagnostics or images when
running tasks in a release? This feature enables users to upload
additional files during deployments. To upload a new file, use the
following agent command in your script:
Write-host "##vso[task.uploadfile]"
The file is then available as part of the release logs. When you
download all the logs associated with the release, you will be able to
retrieve this file as well.
You can also add a powershell script task in your release definition to read the smoke test output and output it to the console. Then you will be see the content of the log files from "Logs" tab powershell script step. And you can also click "Download all logs as zip" to download the smoke test result files.

Azure DevOps Pipeline not finding edmx resources

I have a .Net Core 3.1 MSTest project that calls a separate class library that connects to my database, which was done database-first so I have a .edmx file. It all runs fine locally, but when I push it out to my Azure DevOps Pipeline I start getting a Unable to load the specified metadata resource. exception. I've tested this out by putting in a bit of code to print out all the resources in the assembly
var resources = (Assembly with EDMX).Assembly.GetManifestResourceNames();
System.Console.WriteLine("There are " + resources.Length + " resources in the assembly");
foreach (var resource in resources)
{
System.Console.WriteLine(resource);
}
The result on my local computer prints out what I expect
There are 3 resources in the assembly
Model.csdl
Model.msl
Model.ssdl
However, the same run on my Pipeline shows 0 resources
There are 0 resources in the assembly
My build process locally and on my pipeline are the exact same
task: PowerShell#2
inputs:
targetType: 'inline'
script: |
& "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild.exe" $(Build.SourcesDirectory)\MyProject\MyProject.sln
dir $(Build.SourcesDirectory)\MyProject -include ('*.csdl', '*.msl', '*.ssdl') -recurse
& "C:\hostedtoolcache\windows\dotnet\dotnet.exe" test $(Build.SourcesDirectory)\MyProject\Project.Tests\Project.Tests.csproj
Just to make sure the resources actually exist on my Azure Build agent I've added that 2nd powershell command to find my .csdl, .msl, and .ssdl files, and sure enough they do exist
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 5/30/2020 3:54 PM 30772 Model.csdl
-a---- 5/30/2020 3:54 PM 10993 Model.msl
-a---- 5/30/2020 3:54 PM 23351 Model.ssdl
These files are located in $(Build.SourcesDirectory)\MyProject\Project.Models\obj\Debug\edmxResourcesToEmbed
And the property looks to be correctly set in my .csproj
<ItemGroup>
<EntityDeploy Include="ProjectModels.edmx">
<Generator>EntityModelCodeGenerator</Generator>
<LastGenOutput>ProjectModels.Designer.cs</LastGenOutput>
</EntityDeploy>
</ItemGroup>
I don't use .edmx database designs often, so I'm unfamiliar on how it is suppose to handle the resources, are they suppose to get compiled into the assembly, or are they just loaded at runtime? My build process both locally and in my Pipeline both show:
Skipping target "EntityDeployNonEmbeddedResources" because it has no outputs.
EntityDeployEmbeddedResources:
Processing 1 EDMX files.
Starting to process input file 'ProjectModels.edmx'.
Finished processing input file 'ProjectModels.edmx'.
Finished processing 1 EDMX files.
Not sure what that indicates, but since it occurs on both I'm assuming its not part of the issue. The only other difference that I can think of is my Azure Pipeline uses Visual Studio 2019 Enterprise, while my local build uses Visual Studio 2019 Community.
Any ideas on what I can do to get these resources to load on my Pipeline build?
Azure DevOps Pipeline not finding edmx resources
This issue should comes from the dotnet test.
AFAIK, dotnet cli does not support embed edmx resources. These types of files are supported in MSBuild props/targets that don't ship in the CLI and only ship in full framework VS.
You could check this ticket for some more details.
And the remaining work for this is already tracked at dotnet/ef6#231.
Hope this helps.

How to inlude multiple doxyfiles in a master doxyfile?

I am working on a project which has multiple modules with their own doxyfiles. My idea is to have a single master doxyfile which can include other private doxyfiles to create a one big documentation of the project. The directory structure looks like following:
MyProject+
|-Private_Prj1+
| |-Doc+
| |-doxyfile_privateprj1
|-Private_Prj2+
|-Doc+
|-doxyfile_privateprj2
|-Doc+
|-doxyfile_myproject(AKA Master Doxyfile)
How can I configure the doxyfile_myproject to include doxyfile_privateprj1 and doxyfile_privateprj2 in such a way that when I run Doxygen on the doxyfile_myproject, it then sequentially runs other doxyfiles?

Rails 3.1 - how can I tell if assets are precompiling on production?

Trying to get the hang of deploying a rails 3.1 App ...
Based on what I've read, I've put the following code in my deploy.rb:
before "deploy:symlink", "assets:precompile"
namespace :assets do
desc "Compile assets"
task :precompile, :roles => :app do
run "cd #{release_path} && rake RAILS_ENV=#{rails_env} assets:precompile"
end
end
But to tell you the truth, I can't notice any difference with or without it. Is there something I'm missing here?
EDIT* found the answer:
http://spreecommerce.com/blog
To pre-compile assets for production you would normally execute the following rake task (on the production server).
$ bundle exec rake assets:precompile
This would write all the assets to the public/assets directory while including an MD5 fingerprint in the filename for added caching benefits.
NOTE: In production all references to assets from views using image_tag, asset_path, javascript_include_tag, etc. will automatically include this fingerprint in the file name so the correct version will be served.
There is configuration to do, but it should be correctly set by default. Get in your config/application.rb and see if you find this:
if defined?(Bundler)
# If you precompile assets before deploying to production, use this line
Bundler.require(*Rails.groups(:assets => %w(development test)))
# If you want your assets lazily compiled in production, use this line
# Bundler.require(:default, :assets, Rails.env)
end
...
config.assets.enabled = true
You should also have those in your production.rb file:
# Compress JavaScripts and CSS
config.assets.compress = true
# Don't fallback to assets pipeline if a precompiled asset is missed
config.assets.compile = false
This should be set that way. Is it?