|
complete rewrite
|
1 |
Files with name endind by .hangar are sourced (bash syntax). |
| 2 |
Please have a look into the two provided to check how it is done |
|
| 3 | ||
| 4 |
Each file must contains: |
|
| 5 |
- variable `hangar` definition as an associative array with at least the |
|
| 6 |
following keys: |
|
| 7 |
name: the human identifier of the hangar |
|
| 8 |
url: the url of the remote repository this is the unique identifier for |
|
| 9 |
each hangar, can't be the same in more than one hangar) |
|
| 10 |
type: the type of repo (git, svn, ...) at the moment, only git and svn |
|
| 11 |
repos are known and verified by installation status routine |
|
| 12 |
path: the local path in which the remote repo (or part of it) is cloned |
|
| 13 |
active: is the hangar active (1) or not (0) |
|
| 14 |
|
|
| 15 |
- function `parse_repo_history` which describes how to get the hangar content |
|
| 16 |
(initial import and updates) |
|
| 17 |
- function `getfromrepo` which describes how to get |
|
| 18 |
- optional function `on_exit` to describe what to do when exiting the hangar |
|
| 19 | ||
| 20 |
Some functions are provided by the main script to ease the database management: |
|
| 21 |
- add_record <key> <value> |
|
| 22 |
this function record the key with the value, these |
|
| 23 |
keys are intended to be information for aircraft. |
|
| 24 |
Mandatory keys are: |
|
| 25 |
name : the name of the aircraft |
|
| 26 |
revision : the revision from the repo |
|
| 27 |
date : date of the last update |
|
| 28 |
author : author of the commit |
|
| 29 | ||
| 30 |
- get_record [key] |
|
| 31 |
returns the value recorded for the key if no key is |
|
| 32 |
provided, prints all the recorded keys in the form: |
|
| 33 |
key1 = value1 |
|
| 34 |
key2 = value2 |
|
| 35 |
... (maybe useful for debugging) |
|
| 36 | ||
| 37 |
- add_aircraft |
|
| 38 |
adds aircraft in the database in a buffer table, ready to be |
|
| 39 |
integrated into the main aircrafts table by using `apply_revision` function. |
|
| 40 |
If one or more of the mandatory keys as decribed in `add_record` is or are |
|
| 41 |
missing, the function may exit as an error and the the whole script exits |
|
| 42 | ||
| 43 |
- add_setxml_for_aircraft <aircraft> <-set.xml file> |
|
| 44 |
add in special buffer table the -set.xml entry for aircraft |
|
| 45 |
the trailing "-set.xml" is removed if found |
|
| 46 | ||
| 47 |
- xmlgetnext |
|
| 48 |
in a while loop to read the XML content of a file, export $TAG |
|
| 49 |
(formatted) and $VALUE (not formatted) By design the first couple TAG/VALUE is |
|
| 50 |
always empty, some files have an unidentified issue that make enter teh while |
|
| 51 |
loop in an infinite loop. To avoid this, please use the following syntax: |
|
| 52 | ||
| 53 |
unset xmlgetnext_empty_tag |
|
| 54 |
while xmlgetnext; do |
|
| 55 |
# PUT HERE YOUR STUFF |
|
| 56 |
done < /your/xml/file |
|
| 57 | ||
| 58 |
- sqlite_request <SQLite request> |
|
| 59 |
perform the request on database (actually in |
|
| 60 |
a copied database which will be dumped into the original at the end of |
|
| 61 |
the script). |
|
| 62 |
Don't touch the original database, and always use this |
|
| 63 |
wrapper, unless you will lose your changes at the end. |
|
| 64 |
Moreover this wrapper write in a file /dev/shm/sqlite_request all the |
|
| 65 |
requests, so it is useful to debug, or just watch what is doing |
|
| 66 | ||
| 67 |
- apply_revision |
|
| 68 |
use the buffered tables to feed the main tables with all the |
|
| 69 |
information it will find by parsing the new or updated aircrafts config files |
|
| 70 | ||
| 71 |
Some variables are available |
|
| 72 |
- $latest_revision the revision to starts the history remote retrieving, |
|
| 73 |
defaults to 1 |
|
| 74 | ||
| 75 |
- $tempid a single identifer to create temporary files (useful to get all the |
|
| 76 |
files generated by the script ending with the same ID) |
|
| 77 | ||
| 78 |
Enjoy adding your preferred hangar :) |