I'm using kustomize binary to craft specific kubernetes deployment yaml files.
{Version:kustomize/v3.8.1
GitCommit:0b359d0ef0272e6545eda0e99aacd63aef99c4d0
BuildDate:2020-07-16T00:58:46Z GoOs:linux GoArch:amd64}
Here is my directory structure:
overlays
├── parser
│ ├── dev
│ │ └── nonsec
│ │ ├── dev-patches-parsers-tests.yaml
│ │ ├── dev-patches-parsers.yaml
│ │ └── kustomization.yaml
│ ├── prod
│ │ ├── nonsec
│ │ │ ├── kustomization.yaml
│ │ │ ├── prod-patches-parsers-tests.yaml
│ │ │ └── prod-patches-parsers.yaml
│ │ ├── sec
│ │ │ ├── kustomization.yaml
│ │ │ ├── prod-patches-parsers-sec-tests.yaml
│ │ │ ├── prod-patches-parsers-sec.yaml
│ │ │ ├── prod-patches-parsers-tests.yaml
│ │ │ └── prod-patches-parsers.yaml
│ │ └── v3r
│ │ └── empty.txt
│ ├── stage
│ └── suit
Notice that overlays/parser/prod/nonsec and /overlays/parser/prod/sec contain two identical patch file sets. I want to factor out the common files and push them up one level under prod - I don't want copies of same patches in multiple dirs. I want both nonsec and sec builds to use the same set of prod-patches but I don't know how to do that with kustomize. I've tried to put them in the dir above, but kustomize doesn't allow any references to patch files in the directories above - which is what I NEED to do.
How can I avoid duplication of these prod-patches*.yaml files in multiple dirs?!
Here is my nonsec kustomization.yaml
# Use this as the base code
resources:
- ../../../../base
# Decorate the base code with the following components
components:
- ../../../../components/common-all
- ../../../../components/common-prod
- ../../../../components/parser
# Then finally, patch the results from above with this:
patchesStrategicMerge:
- prod-patches-parsers.yaml
- prod-patches-parsers-tests.yaml
And this is my sec kustomization.yaml:
# Use this as the base code
resources:
- ../../../../base
# Decorate the base code with the following components
components:
- ../../../../components/common-all
- ../../../../components/common-prod
- ../../../../components/parser
# Then finally, patch the results from above with this:
patchesStrategicMerge:
- prod-patches-parsers.yaml
- prod-patches-parsers-tests.yaml
- prod-patches-parsers-sec.yaml
- prod-patches-parsers-sec-tests.yaml
You could do the following:
overlays
├── parser
│ ├── dev
│ │ └── nonsec
│ │ ├── dev-patches-parsers-tests.yaml
│ │ ├── dev-patches-parsers.yaml
│ │ └── kustomization.yaml
│ ├── prod
│ │ ├── kustomization.yaml
│ │ ├── prod-patches-parsers-tests.yaml
│ │ ├── prod-patches-parsers.yaml
│ │ ├── nonsec
│ │ │ └── kustomization.yaml
│ │ ├── sec
│ │ │ ├── kustomization.yaml
│ │ │ ├── prod-patches-parsers-sec-tests.yaml
│ │ │ └── prod-patches-parsers-sec.yaml
│ │ └── v3r
│ │ └── empty.txt
with overlays/parser/prod/kustomization.yaml:
resources:
- ../../../../base
- ../../../../components/common-all
- ../../../../components/common-prod
- ../../../../components/parser
patchesStrategicMerge:
- prod-patches-parsers.yaml
- prod-patches-parsers-tests.yaml
overlays/parser/prod/nonsec/kustomization.yaml:
resources:
- ../
overlays/parser/prod/sec/kustomization.yaml:
resources:
- ../
patchesStrategicMerge:
- prod-patches-parsers.yaml
- prod-patches-parsers-tests.yaml
The overall directory structure is a bit complex and you might want to simplify or flatten it.
Related
I am trying to create a debian package for a postgreSQL extension Apache-age release 1.1.1 and created the directory structure using dh_make command.
The directory structure is as follows:
age-1.1.1 (project root)
├── debian
│ ├── changelog
│ ├── compat
│ ├── control
│ ├── docs
│ ├── examples
│ ├── links
│ ├── manpages
│ ├── menu
│ ├── postinst
│ ├── postrm
│ ├── preinst
│ ├── prerm
│ ├── rules
│ ├── source
│ └── watch
├── src
└── Makefile
The dpkg-buildpackage -b when run from project-root folder it looks for debian folder, then reads the rule file, then reads the Makefile located in the project root to build the package.
I want to change the directory structure to the following:
.project root
├── packaging
│ ├── debian
│ │ ├── control
│ │ ├── control.in
│ │ ├── changelog
│ │ ├── copyright
│ │ ├── pgversions
│ │ ├── rules
│ │ └── ...
│ └──
├── src
├── LICENSE
├── README.md
├── Makefile
└── ...
I want to change the directory structure so that the dpkg-buildpackage -b command can be run from the packaging folder and it should build the package.
Inside your Makefile
Modify the install paths accordingly. It should point to your packaging/debian/* where * is the filename.
This way the Makefile can point to the correct file path target inside the new folder structure.
I'm not sure if this is the best way to do this but it's working for me:
Here are the steps:
First run the dh_make_pgxs command from the project root directory.
Create a packaging directory in the project root and move the debian directory created in step 1 to this directory along with the Makefile, age.control and the age--1.1.1.sql.
Your file structure should look like this:
.project root
├── packaging
│ ├── debian
│ │ ├── control
│ │ ├── control.in
│ │ ├── changelog
│ │ ├── copyright
│ │ ├── pgversions
│ │ ├── rules
│ │ └── ...
│ ├── age--1.1.1.sql
│ ├── age.control
│ ├── Makefile
│ └── ...
├── src
├── LICENSE
├── README.md
└── ...
Change the file paths in the Makefile like:
src/backend/age.o should be ../src/backend/age.o.
./tools/ should be ./../tools/.
and so on.
Now you can simply run the dpkg-buildpackage -b command from the packaging directory to build the debian package.
Note: In step 1 we are running dh_make_pgxs in the project root first, this is to make sure that the project name in the control files and the version in the changelog file are correct. In this case the name/source in control, control.in & changelog files should be apache-age and the version number in changelog file should be 1.1.1-1.
Alternatively, you can run the command from the packaging directory and manually change the name and version in the control and changelog files.
I have a C project that is structured like so:
.
├── Makefile
├── c_kernels
│ ├── cuda
│ │ ├── Makefile
│ │ ├── kernel_interface.h
│ │ └── kernel.cu
│ ├── omp3
│ │ ├── Makefile
│ │ ├── kernel_interface.h
│ │ └── kernel.c
│ ├── omp4
│ │ ├── Makefile
│ │ ├── kernel_interface.h
│ │ └── kernel.c
│ ├── omp4_clang
│ │ ├── Makefile
│ │ ├── kernel_interface.h
│ │ └── kernel.c
│ └── serial
│ ├── Makefile
│ ├── kernel_interface.h
│ └── kernel.c
├── drivers
│ ├── Makefile
│ ├── kernel_interface.h
│ └── kernel_driver.c
├── kernel_interface.h
├── main.c
├── make.deps
└── make.flags
The makefile is configured so you would make the project like so (for omp3):
$ make KERNELS=omp3
How can I generate the Doxygen documentation for a project in this kind of structure for one type of kernel at a time?
Is it that I will need to have a Doxygen configuration for each kernel type?
Or should I add a docs build target in my makefile and then build the documentation based upon the target kernel?
i'm not sure why/when this started, but frequently I get an auto-suggestion for a value that exists in my code, but with the last letter missing. It's not one single case, it happens a lot.
I'm running version 1.6.0
Here's my package list:
Built-in Atom packages (89)
├── about#1.3.0
├── archive-view#0.61.0
├── atom-dark-syntax#0.27.0
├── atom-dark-ui#0.51.0
├── atom-light-syntax#0.28.0
├── atom-light-ui#0.43.0
├── autocomplete-atom-api#0.10.0
├── autocomplete-css#0.11.0
├── autocomplete-html#0.7.2
├── autocomplete-plus#2.25.0
├── autocomplete-snippets#1.10.0
├── autoflow#0.27.0
├── autosave#0.23.0
├── background-tips#0.26.0
├── base16-tomorrow-dark-theme#1.1.0
├── base16-tomorrow-light-theme#1.1.1
├── bookmarks#0.38.2
├── bracket-matcher#0.79.0
├── command-palette#0.38.0
├── deprecation-cop#0.54.0
├── dev-live-reload#0.47.0
├── encoding-selector#0.21.0
├── exception-reporting#0.37.0
├── find-and-replace#0.197.4
├── fuzzy-finder#0.94.0
├── git-diff#0.57.0
├── go-to-line#0.30.0
├── grammar-selector#0.48.0
├── image-view#0.56.0
├── incompatible-packages#0.25.0
├── keybinding-resolver#0.33.0
├── language-c#0.51.1
├── language-clojure#0.19.1
├── language-coffee-script#0.46.0
├── language-csharp#0.11.0
├── language-css#0.36.0
├── language-gfm#0.84.0
├── language-git#0.12.1
├── language-go#0.42.0
├── language-html#0.44.0
├── language-hyperlink#0.16.0
├── language-java#0.17.0
├── language-javascript#0.110.0
├── language-json#0.17.4
├── language-less#0.29.0
├── language-make#0.21.0
├── language-mustache#0.13.0
├── language-objective-c#0.15.1
├── language-perl#0.32.0
├── language-php#0.37.0
├── language-property-list#0.8.0
├── language-python#0.43.0
├── language-ruby#0.68.0
├── language-ruby-on-rails#0.25.0
├── language-sass#0.45.0
├── language-shellscript#0.21.0
├── language-source#0.9.0
├── language-sql#0.20.0
├── language-text#0.7.0
├── language-todo#0.27.0
├── language-toml#0.18.0
├── language-xml#0.34.2
├── language-yaml#0.25.1
├── line-ending-selector#0.3.0
├── link#0.31.0
├── markdown-preview#0.157.2
├── metrics#0.53.1
├── notifications#0.62.1
├── one-dark-syntax#1.2.0
├── one-dark-ui#1.1.9
├── one-light-syntax#1.2.0
├── one-light-ui#1.1.9
├── open-on-github#0.41.0
├── package-generator#0.41.0
├── settings-view#0.232.3
├── snippets#1.0.1
├── solarized-dark-syntax#1.0.0
├── solarized-light-syntax#1.0.0
├── spell-check#0.65.0
├── status-bar#0.83.0
├── styleguide#0.45.1
├── symbols-view#0.110.1
├── tabs#0.91.3
├── timecop#0.33.0
├── tree-view#0.203.2
├── update-package-dependencies#0.10.0
├── welcome#0.33.0
├── whitespace#0.32.1
└── wrap-guide#0.38.1
/Users/me/.atom/packages (26)
├── Stylus#1.0.0
├── activate-power-mode#0.4.1
├── atom-beautify#0.28.24
├── atom-jade#0.3.0
├── atom-material-ui#0.8.0
├── auto-indent#0.5.0
├── autoclose-html#0.22.0
├── emmet#2.4.1
├── file-icons#1.6.19
├── git-diff-details#0.20.0
├── highlight-selected#0.11.2
├── idiomatic-dark-syntax#0.1.3
├── language-cjsx#0.3.0
├── language-javascript-jsx#0.3.7
├── linter#1.11.3
├── linter-coffeelint#1.1.2
├── linter-eslint#5.2.6
├── merge-conflicts#1.3.2
├── pigments#0.26.0
├── predawn-ui#1.0.2
├── pretty-json#0.4.1
├── react#0.14.1
├── react-snippets#0.1.4
├── seti-ui#0.8.1
├── spacegray-dark-neue-ui#1.4.0
└── spacegray-dark-ui#0.12.0
As it turns out this is a defect in the language-cjsx package. If you open the Chrome Developer Tools with CtrlAltI and inspect the function name tokens as identified by the grammar there is an unnecessary span element surrounding the last character of every function name.
I have managed to solve this in my fork by simply removing the mapping between one of the capture groups and the grammar class. Whilst this works, a more elegant solution from Víctor Martínez is available that incorporates all of the recent changes from the CoffeeScript grammar package.
If you want to test this out you can follow the following process:
Uninstall the existing version of the language-cjsx package.
Clone one of the above two forks of language-cjsx to a known directory.
Run apm link <path-to-directory> to symlink the package to Atom's package directory.
Restart Atom with CtrlAltR.
Final Note: Víctor Martínez has subsequently noted that he is currently using orktes/atom-react to obtain syntax highlighting for CJSX based solutions.
Is there any de facto standard for the filesystem output layout of compiled CoffeeScript output?
Or: where should the .js and .map files end up?
I currently have a file watcher1 compiling the output to ./grounds/[whatever] to keep the source folder clean, so I end up with something like:
index.html
/js
├──foo.js
├──bar.js
/coffee
├──a.coffee
├──b.coffee
├──/grounds
│ ├──a.js
│ ├──a.map
│ ├──b.js
│ ├──b.map
├──/some-module
│ ├──c.coffee
│ ├──/grounds
│ │ ├──c.js
│ │ ├──c.map
Just curious if I missed the boat on some existing standard for the output file layout, or if folks generally just let them all be siblings in the same folder and are happy with that.
1: Pycharm
I don't think they is any standard, but for development, I use the same structure for the JS than for the coffee:
eg:
coffee
├── AdvancedStatsModule.coffee
├── board
│ ├── Board.coffee
│ ├── Card.coffee
├── controllers
│ ├── directives.coffee
│ ├── factory.coffee
│ ├── filters.coffee
│ ├── ListController.coffee
public/js
├── AdvancedStatsModule.js
├── board
│ ├── Board.js
│ ├── Card.js
├── controllers
│ ├── directives.js
│ ├── factory.js
│ ├── filters.js
│ ├── ListController.js
Advantages for this:
JS and coffee are not mixed
The coffee directory is not public
For production, I usually concat and minify my files anyway.
Update:
I use gulp for that. My Gulpfile:
var watch= require('gulp-watch');
var coffee= require('gulp-coffee');
gulp.src(paths.coffee)
.pipe(watch(function(files) {
return files.pipe(coffee())
.pipe(gulp.dest(paths.js));
}));
I have a problem with folder structure of MVC2
How can I use that way:
Folder:
├── Controllers
│ └── Portal
│ ├── Accounting
│ │ ├── CashController.cs
│ │ └── BankController.cs
│ └── HR
│ └── EmployeesController.cs Models
└── Views
└── Portal
└── Accounting
├── Cash
│ ├── Index.aspx
│ └── List.aspx
├── Bank
│ └── Index.aspx
└── HR
├── Index.aspx
└── Employee.aspx
How can I use folder structure like that and how can I route the URL with the right form.
Many Thanks
You might want to consider using Areas and dropping the Portal folder since it's just a wrapper.
So you will end up with something like this :
Areas
├── Accounting
│ ├── Controllers
│ │ ├── CashController.cs
│ │ └── BankController.cs
│ └── Views
│ ├── Cash
│ │ ├── Index.aspx
│ │ └── List.aspx
│ └── Bank
│ └── Index.aspx
└── HR
├── Controllers
│ └── EmployeesController.cs
└── Views
└── Employees
├── Index.aspx
└── Employee.aspx
More on Areas here
Or just use any structure you want and change the namesspaces to match the default (not recommended).