If I have a project structured like this:
project
│ README.md
│ config.json
package.json
│
└───folder1
│ │ fileA.js
│ │ fileB.html
│
└───folder2
│ fileC.js
│ fileD.html
How can I add a rule to the CODEOWNERS file that gives a user ownership of only the files in the root folder, but not the files in any of the subdirectories?
I've tried the following but none of them seem to work the way I want:
# CODEOWNERS
/ #johnSmith
./ #johnSmith
/* #johnSmith
After some experimenting this seems to work:
#CODEOWNERS
/*.* #userName
/apps #differentUserName
That will give #userName ownership of root files. It also applies to files inside dot-prefix folders, like .github/ or .vscode/ but no other nested directories
Related
How to disable this message:
┌───────────────────────────────────────────────────────────────────────────────────┐
│ Share your Cucumber Report with your team at https://reports.cucumber.io │
│ Activate publishing with one of the following: │
│ │
│ src/test/resources/cucumber.properties: cucumber.publish.enabled=true │
│ src/test/resources/junit-platform.properties: cucumber.publish.enabled=true │
│ Environment variable: CUCUMBER_PUBLISH_ENABLED=true │
│ JUnit: #CucumberOptions(publish = true) │
│ │
│ More information at https://reports.cucumber.io/docs/cucumber-jvm │
│ │
│ Disable this message with one of the following: │
│ │
│ src/test/resources/cucumber.properties: cucumber.publish.quiet=true │
│ src/test/resources/junit-platform.properties: cucumber.publish.quiet=true │
└───────────────────────────────────────────────────────────────────────────────────┘
What steps to take?
In the message it is saying as below:
Disable this message with one of the following:
src/test/resources/cucumber.properties: cucumber.publish.quiet=true
src/test/resources/junit-platform.properties: cucumber.publish.quiet=true
For me it was disabled after doing both of the above
create a new cucumber.properties file under rc/test/resources/ and then add this line
cucumber.publish.quiet:true
I've got the same problem here and I solved it by following the steps in the message:
Creating cucumber.properties and junit-platform.properties in "src/test/resources" on the Package Explorer;
Adding the line "cucumber.publish.quiet=true" to each one of them.
At times the resources folder might not be there by default on eclipse , then you would need to create a folder under src/test by the name 'resources' and the create 2 sub-folders under that folder named 'cucumber.properties' and 'junit-platform.properties' and add that declaration under both.
cucumber.publish.quiet=true
For disabling the cucumber publish message in console,reference for console Message.
Create a file named "cucumber.properties" in src/test/resources file path(which by default gets created when we create a new project in eclipse). Mention cucumber.publish.quite=true in the properties file. That's it now you won't see that cucumber content in the console.
reference image.
If using the same nuget package(s) over multiple solutions, how do I keep them up to date without having to open up every solution and update packages when a new version is released?
Folder structure is typically something like this but over many more projects. Each project has its own packages.config with various package references.
$tfs/
├── Solution One/
│ ├ Solution 1.sln
│ ├ nuget.config (solution item)
│ ├── Packages/
│ ├ ├── Newtonsoft.JSON.12.0.2/
│ ├ ├── Jquery3.1.4/
│ ├── Project one/
│ ├ ── packages.config
│ ├ ── whatever.cs
│ ├ ── folder /
│ ├ ── another folder /
│ ├── Project Two/
│ ├ ── packages.config
│ ├ ── file.cs
│ ├ ── folder/
│ ├ ── another folder/
├── Solution Two/
│ ├ Solution 2.sln
│ ├ nuget.config
│ ├── Packages/
│ ├ ├── Newtonsoft.JSON.11.1.0/
│ ├ ├── Jquery1.3.4/
│ ├── Project one/
│ ├ ── packages.config
│ ├ ── whatever.cs
│ ├ ── folder /
│ ├ ── another folder /
│ ├── Project two/
│ ├ ── packages.config
│ ├ ── file.cs
│ ├ ── folder/
│ ├ ── another folder/
I have tried running this powershell in Package Manager Console but this only applies to one solution at a time:
$packageId = "jquery"
Get-ChildItem *.sln -recurse | %{.\\nuget.exe restore $_.fullname}
Get-ChildItem packages.config -Recurse `
| Where-Object {$_ | Select-String -Pattern $packageId} `
| %{.\\nuget.exe update -Id $packageId $_.FullName}
Do I need to update packages.config in each solution of each project and open them in order to get the updates? I would have thought there would be an easier way to do this. I am using a private nuget server if it makes a difference.
Note: I have looked at this question: Updating nuget packages in all projects in a solution and it is not the same scenario as mine. I'm looking to update packages across multiple solutions, not multiple projects in one solution.
As #imps said in the comments, there's no solution for packages.config projects across solutions. Within a solution you can use the NuGet Package Manager UI's "Manage packages for solution" and the consolidate tab helps makes sure all projects use the same version, but you'll need to repeat this for all solutions.
If you migrate from packages.config to PackageReference, you could take advantage of MSBuild extensibility and either import a common props file, or if using Visual Studio 2017 or newer, use Directory.Build.Props in the highest common parent directory of all the projects.
In your props file, you define the versions of the packages you care about, something like this:
<Project>
<PropertyGroup>
<NewtonsoftJsonVersion>12.0.1</NewtonsoftJsonVersion>
</PropertyGroup>
</Project>
and then in your csproj files, use <PackageReference Include="Newtonsoft.Json" Version="$(NewtonsoftJsonVersion)" />. The issue with this is that you can no longer use the Package Manager UI or Package Manager Console in VS to upgrade (well you can, but it'll change it in the csproj, not your props file), but you can still use the UI to check for updates. If you add your props file to your solution, then it just takes two clicks and a few taps on your keyboard to update, so it's really not a big deal.
In your example, the common parent directory would be the TFS root, so $/Directory.Build.props. The problem with this is if you use CI and have a trigger to run the Solution One build on changes to $/Solution One/* and run the Solution Two build on changes to $/Solution Two/*, then they'll both miss changes to $/Directory.Build.props. Or maybe it is possible to configure TFS build triggers to include it, but I don't remember because I haven't used TFVC is such a long time.
However, the bigger issue is that in your example, it's clear you're using the jQuery package. This uses content, which copies files into your project on install/upgrade. PackageReference doesn't work this way (it's listed as a package compatibility issue) , so unless you want to have a different process for upgrading jQuery and any other js/css in your web projects, you can't migrate ASP.NET projects to PackageReference. Note that ASP.NET Core projects are SDK style which only support PackageReference, not packages.config, and typically use either LibMan or npm to get css and javascript.
Customers who can migrate to SDK style projects, they could even consider using this SDK for central package management that helps ensure you don't accidently leave a version number in your csproj.
Currently I have 2 projects, both with the same structure: all source goes to folder src.
src
└───folder1
│ │ file011.js
│ │ file012.js
│ └───...
└───folder2
│ │ file021.js
│ └───file022.js
│
│ services.js
Somewhere deep down in src folder, I have
import { ClassA} from 'services';
where services is direct child file inside src folder.
In 1 project, opened with Code-Insiders, i get full intellisense on ClassA, but nothing in the other. Wonder what causes the different behavior between the 2 and how I can adjust that.
Currently I have a bunch of files living in a directory under TFS. Essentially I want to make a NuGet package out of it in my build server.
I do want however to move the file structure into a sub-directory and re-base from there. Let me explain:
The TFS path watched is: $/Foo/Bar/
$/Foo/Bar/
│
│ Bar.nuspec
│
└───PackageContent/
│ GenPumpGraphCtrl.dll
│ MultiPumpCurve.dll
│ PumpGraphCtrl2.dll
│
├───Dwg/
│ Logofnt1.wmf
│ LOGOFNT1a.wmf
│ LOGOFNT1b.wmf
│
├───Ref/
│ AqSolutions.xbn
│ Astring.bin
│ WordTranslation.xbn
│
└───Temp/
│
└───Notes/
Notes.txt
My .nuspec uses:
<files>
<file src="PackageContent\**"/>
</files>
However, I want to rename the PackageContent directory to .package-content and updated my .nuspec:
<files>
<file src=".package-content\**"/>
</files>
But by NuGet Pack step in TeamCity complains with the following error:
>> Cannot create a package that has no dependencies nor content.
Are .dot-prefixed directories somewhat hidden from TFS?
Are .dot-prefixed directories automatically ignored by the some obscure rule in the .nuspec?
Further investigation into the problem shows that in fact, if I place any .dot-prefixed directory, it gets entirely excluded from my NuGet package, despite using a wildcard.
The question is clearer now: How can I ensure I really include everything? Including .dot-prefixed directories?
Ok, in fact there is this obscure -NoDefaultExcludes parameter for nuget pack.
In my case, I had to add it to the Command line parameters box for the TeamCity NuGet Pack step:
I guess I didn't upgrade the right way, but for a while I was running two versions of Perl concurrently. Now I just have one, but every time I start PPM it recreates the Perl folder of one of the old locations. I've set the active one to be the current Perl folder, but because the old one is still present on the list (displayed when I go Edit->Preferences), it creates it every time. How do I get it to stop doing that? I looked through the Windows Registry but I don't think that's where the areas are tracked.
This is ActiveState Perl 5.10.1 build 1006 on Windows Server 2003.
My new guess is that ppm is looking in Config.pm (which is generated at install time) for the locations. Again, if you use the correct ppm, it will pick up the correct paths.
This could be way off topic, but I had to move our group's Perl install from one network drive/server (W:) to another (Z:). I had lots of problems with the PPM site stuff too (mostly because I wanted to change to a non-standard "user" area) so I wrote everything down (in case I every had to do it again).
Hopefully, some of this is useful to Kev, or any others looking at this.
1) Install the latest ActivePerl distribution. In this case, it was 5.8.8 build 820. I installed this into Z:\Software\Perl\5.8.8, with the intention that Z:\Software\Perl\site\lib would be the “user” area for installing Packages, instead of the default Z:\Software\Perl\5.8.8\site\lib.
2) Set the new Perl “bin” dir to be first on my PATH and open up a DOS prompt. Type “ppm area” and you should see the following areas:
┌────────────┬──────┬─────────────────────────────────┐
│ name │ pkgs │ lib │
├────────────┼──────┼─────────────────────────────────┤
│ (Software) │ n/a │ Z:/Software/Perl/site/lib │
│ perl │ 0 │ Z:/Software/Perl/5.8.8/lib │
│ site* │ 0 │ Z:/Software/Perl/5.8.8/site/lib │
└────────────┴──────┴─────────────────────────────────┘
3) I needed to get “site” turned to “(site)” (read-only) and “(Software)” turned to the default, writable PPM Area. Also, I didn’t like the name “Software” (picked up from the beginning of the path on Z:, I assume), so I also wanted to rename it to “user”.
4) Run the full PPM GUI (type “ppm” in DOS) and set Software as the default Area (Edit -> Preferences) and install something easy (I usually pick MP3-Info).
5) Exit the GUI and run “ppm area” again to get:
┌──────────┬──────┬─────────────────────────────────┐
│ name │ pkgs │ lib │
├──────────┼──────┼─────────────────────────────────┤
│ Software │ 1 │ Z:/Software/Perl/site/lib │
│ perl │ 0 │ Z:/Software/Perl/5.8.8/lib │
│ site* │ 0 │ Z:/Software/Perl/5.8.8/site/lib │
└──────────┴──────┴─────────────────────────────────┘
6) For some reason, “ppm area” isn’t showing Software as the default Area, even though I did select it as the default inside PPM’s preference. Don’t worry about this yet.
7) Go to Z:\Software\Perl\site\lib\etc and rename the DB file to “ppm-user-area.db". Go to Z:\Software\Perl\5.8.8 and remove ALL write-permissions to the “site” folder and all sub-folders. Run “ppm area” again and you should see:
┌────────┬──────┬─────────────────────────────────┐
│ name │ pkgs │ lib │
├────────┼──────┼─────────────────────────────────┤
│ user* │ 1 │ Z:/Software/Perl/site/lib │
│ perl │ 42 │ Z:/Software/Perl/5.8.8/lib │
│ (site) │ 0 │ Z:/Software/Perl/5.8.8/site/lib │
└────────┴──────┴─────────────────────────────────┘
8) You should now be all set! You default PPM Area is “user” (Z:\Software\Perl\site\lib) and the “site” Area (Z:\Software\Perl\5.8.8\site\lib) is not writable (this is important because it’s not on Perl’s search path – if someone installed Packages in there, Perl wouldn’t be able to find them!).
I did have some problems getting PPM to recognize all the Packages intalled in the “perl” Area. It kept listing that Area as locked in the PPM GUI Preferences. Eventually, I deleted the PPM DB file in Z:\Software\Perl\5.8.8\etc and the PPM GUI could magically find everything!
Replace all references throughout .packlists (and possibly all other files under the Perl path as well), then delete the .db files in etc/ and site/etc, then run ppm to let it re-build the database based on the updated packlists.
So the answer is some combination of Config.pm, lib\Config_heavy.pl, lib\CORE\config.h, possibly other files, the .dbs, and the .packlists.
Although, who's to say if I had left the Windows Registry entries there too it wouldn't've found them?