Not a bug, just an FYI to anyone using subdirectories
rit001 opened this issue · comments
The image-create script has been coded to take the path from which it is run and then use it as the root directory for certain other steps. This is all handled by the use of the SCRIPT_DIR variable.
This does not cause any issues if everything is placed in a single directory or the script is placed at the top level of any tree structure that is defined. It does cause a complication if the script itself is placed in a sub-directory.
In the environment I am putting together the impact is on the -d --destination switch as any path passed must be offset from the location of the script, rather than the 'root' directory. -s --source does not have this issue as the function extract_images has not been written to use SCRIPT_DIR.
The result is that the command line for image-create ends up looking something like this
bin/image-create.sh -a
-k
-n jammy
-u config_files/scaleway-1-network-basic
-s iso_store/ubuntu-22.04.1-live-server-amd64.iso
-d ../iso_output/ubuntu-22.04.1-test-amd64.iso
So
- the script is found in bin/
- config files are in config_files/
- source iso image is in iso_store/
- destination iso is placed in iso_output/ but must be defined as a path offset from bin/
You may be wondering why I'm making such a complex structure. My aim is to have an environment that can create a number of different ISOs for CI and production environments, which will be complicated even more by the use of ytt Carvel tools which will allow me to have a far more dynamic YAML environment.
This is indeed a pitfall. Been there by putting the script into /usr/bin, since I wanted to keep the workspace as clean as possible.
Re-opening temporarily to allow for comments/opinions after merging #16 which updates the structure to use /app and /data, as well as updated the docker containers and CI jobs.
Also went ahead and generated a new release. Thanks to everyone for their contributions 🥳
Glad I could help. This is a really handy tool.
You should probably update the overview here: https://hub.docker.com/r/deserializeme/pxeless
It could also be really great if the release tags was on docker hub too.
Adding the missing releases on docker would allow we to use the image directly, instead of installing the binary in an image. 😉
@Poeschl I believe what you are looking for is already on docker hub but only a "latest" tag, no v0.0.2 tag. Try:
docker pull deserializeme/pxeless:latest && docker run --rm --volume "$(pwd):/data" --user $(id -u):$(id -g) deserializeme/pxeless -a -u user-data.basic -n focal
@lmunch The image is there, yes. But to use it in an production environment I will not use the latest tag ;)