|
| 1 | +# TODO for configurable-company |
| 2 | + |
| 3 | +- [ ] `checkout.sh`: Necessary only if using submodules |
| 4 | +- [ ] `clean-checkout.sh`: Could be optimized if not using submodules |
| 5 | +- [ ] `clone.sh`: Necessary only if using Git LFS |
| 6 | +- [ ] `copr.sh`: Necessary only if using GitHub Enterprise |
| 7 | +- [ ] `enable-public-push.sh`: Necessary only if working additionally with github.com |
| 8 | +- [ ] `help.sh`: Help should be generated out of single commands. |
| 9 | + Maybe some commands will be skipped for a certain company |
| 10 | +- [ ] `install-helper.ps1`: to be analyzed |
| 11 | +- [ ] `install.bat`: to be analyzed |
| 12 | +- [ ] `install.sh`: to be analyzed |
| 13 | +- [ ] `mkpr.sh`: Necessary only if using GitHub Enterprise |
| 14 | + - [x] Variables needs to be renamed (`GITHUB_*` => `GHE_*`) |
| 15 | + - [x] `adsk` needs to be replaced with `$KIT_ID` |
| 16 | + - [ ] slug specific code must be isolated |
| 17 | +- [ ] `mkrepo.sh`: Necessary only if using GitHub Enterprise |
| 18 | + - [x] Variables needs to be renamed (`GITHUB_*` => `GHE_*`) |
| 19 | +- [ ] `paste.sh`: Necessary only if using GitHub Enterprise |
| 20 | + - [x] Variables needs to be renamed (`GITHUB_*` => `GHE_*`) |
| 21 | +- [ ] `pull.sh`: Necessary only if using submodules |
| 22 | +- [ ] `setup.sh`: Split different tasks into separate scripts for better tailoring |
| 23 | +- [x] `show-deleted.sh`: OK |
| 24 | +- [ ] `teardown.sh`: Contains string << YOUR GITHUB SERVER >>. Should be replaced with |
| 25 | + `$GHE_SERVER` |
| 26 | +- [x] `version.sh`: OK |
| 27 | + |
| 28 | +## Features |
| 29 | +- Submodules |
| 30 | +- Git LFS |
| 31 | +- GitHub Enterprise |
| 32 | + |
| 33 | +## Platforms |
| 34 | +- Windows |
| 35 | +- Mac OSx |
| 36 | +- Linux |
| 37 | + |
| 38 | +## Use Cases |
| 39 | + |
| 40 | +### Company adds company specific script |
| 41 | +There shall be a way to store company specific scripts. These scripts shall be |
| 42 | +included in help, ... |
| 43 | + |
| 44 | +### Company patches generic script |
| 45 | +There shall be a way to patch existing generic scripts for a company. |
| 46 | + |
| 47 | +### Company deletes generic script |
| 48 | +There shall be a way to delete generic scripts for a company, because they might |
| 49 | +be dangerous or the use case is not covered in that company. |
| 50 | + |
| 51 | +### Company updates generic scripts |
| 52 | +When updating the generic scripts to a new version then the added, patched and |
| 53 | +deleted scripts shall be kept. It is the repsonsiblity of the company to check |
| 54 | +if the company adaptations are still valid. |
| 55 | + |
| 56 | +### User specific scripts |
| 57 | +If users write own scripts they should not be overwritten when an update is done. |
| 58 | + |
| 59 | +## Design Ideas |
| 60 | + |
| 61 | +### Company specific folder |
| 62 | +On top-level there shall be a new folder with the $KIT_ID name, e.g. adsk which |
| 63 | +contains company specific scripts. When this folder only exists on a branch |
| 64 | +`adsk-production` then a merge would never have a conflict, because this folder |
| 65 | +only exists in that branch and not on the `master` branch. |
| 66 | + |
| 67 | +Proposed directory structure: |
| 68 | +``` |
| 69 | +lib => generic scripts, so move all scripts here |
| 70 | +lib/lnx => generic linux specific scripts |
| 71 | +lib/osx => generic OSx specific scripts |
| 72 | +lib/win => generic windows specific scripts |
| 73 | +lib/other => generic other specific scripts |
| 74 | +<company> => company OS independent scripts |
| 75 | +<company>/lnx => company linux specific scripts |
| 76 | +<company>/osx => company osx specific scripts |
| 77 | +<company>/win => company windows specific scripts |
| 78 | +<company>/other => company windows specific scripts |
| 79 | +``` |
| 80 | + |
| 81 | +### Company adds company specific script |
| 82 | +Put the script in `<company>` folder. |
| 83 | +To get this working the `config.include` must be changed: |
| 84 | +```shell |
| 85 | + ... |
| 86 | + elif [ -e \"$KIT_PATH/<company>/$COMMAND.sh\" ]; then |
| 87 | + bash \"$KIT_PATH/$COMMAND.sh\" $@; \ |
| 88 | + ... |
| 89 | +``` |
| 90 | +### Company Adaptations |
| 91 | +#### Alternative A: disallow features in `enterprise.constants` |
| 92 | +- Some features (= scripts) might be dangerous |
| 93 | +- Based on values in `enterprise.constants` features (= scripts) shall be enabled |
| 94 | + / disabled. |
| 95 | +- Therefore each script must check if the feature is allowed to avoid direct calls |
| 96 | +- In `config.include` there should be a check if the featrue is allowed before |
| 97 | + calling it |
| 98 | + |
| 99 | +#### Alternative B: setup.sh shall run a company specific setup.sh |
| 100 | +In `setup.sh` at the end run `$KIT_ID/setup.sh` (if it exists) which contains |
| 101 | +company specific setup, e.g. scripts to be added, patched, or removed: |
| 102 | +- Added scripts: copy from a company folder to the main folder |
| 103 | +- Patched scripts: copy and overwrite from a company folder to the main folder |
| 104 | +- Removed scripts: delete from the main folder |
0 commit comments