| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This ensures that the build environment is exactly the same. Furthermore
security risks for the host are minimized.
|
|
It is planned that the sources are first directly downloaded into the
VM. Later they will be cloned on the host, transmitted via rsync to the
VM and the artifacts downloaded from the VM to make the build process
completely offline for reproducibility.
|
|
This waits for a little delay and then tries to run `true` via SSH on
the virtual machine. If this does not work for a maximum amount of
attempts a fatal error is raised and an appropriate log message is
written.
|
|
`busybox` is not installed inside the current VM and there is no strict
reason to use it. `sh` instead should be present on any targeted system.
|
|
This prepares moving the workbench to the virtual machine. It
furthermore adds the following command line arguments:
- image
- port
See `craft --help` or the init() function for details.
|
|
There will likely be a way how a source repository can specify the
default shell commands to build itself for craft. If this will be a pure
shell file, YAML, JSON or something else is not clear for now.
This commit removes the lookup of the craft.sh file and instead adds the
--task command line argument to specify that script code.
This might only be a temporary solution but is the best fit for now.
|
|
|
|
While the exit log message is prefixed with `defer` and thus called at
the end of the main function it is in theory possible that the startup
log message fails. This would result in a exit message without startup
message which is confusing.
Furthermore it is not intuitive while reading the code to see the exit
message first.
|
|
This might be re-used later but the new goal is to make craft an
independent build automation tool or service which might be called by a
later provided git hook.
Nevertheless the primary target for now is to build something which
executes a build based on a repository reference but not triggered by a
Git hook.
|
|
craft.sh is the script which needs to be located inside the repository
root to define how the repository should be used.
The first defined function is `build()` which is used to build the
repository content.
|
|
This commit add the usage of shallow submodule updates. Thus after
checking out the targeted commit of the parent repository only the
required commits of the submodules are fetched.
|
|
This adds support for repositories having submodules. Nevertheless all
the required clone operations are complete which makes this process time
consuming depending on the list of submodules.
|
|
After detecting an update of a Git ref craft should create a throw-away
Git clone of the repository with the new Git commit checked out. This is
the starting point for executing build and test steps.
Improving performance by tree-less or shallow clones and updating
submodules is not yet implemented.
|
|
- exit message
- more consistent messages
- refactoring to implement this
|
|
Since craft should only be referenced by a symlink like that:
ln -s /usr/bin/craft myrepo/.git/hooks/post-receive
It is important to detect the hook type, in this case 'post-receive'.
This commit also validates that the determined hook type is supported.
Currently only the post-receive hook is supported.
|
|
When craft is used - as intended - as Git post-receive hook the current
working directory should always be the .git folder. In case of bare
repositories this should point to the bare repository.
|
|
The first program for this repsoitory will be a Git post-receive hook
which will be used at any source repository which is registered for
automated builds.
|
