write output from build to a file #509
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It is desirable to have a simple machine parseable output file from a build so that it can be consumed in CD/CI systems. We need the source cache, the installed path, and the full path to the build artifact. Signed-off-by: jtimberman <[email protected]>
|
Very helpful!
|
|
📌 Commit 45e84f6 has been approved by |
thesentinels
pushed a commit
that referenced
this pull request
May 13, 2016
It is desirable to have a simple machine parseable output file from a build so that it can be consumed in CD/CI systems. We need the source cache, the installed path, and the full path to the build artifact. Signed-off-by: jtimberman <[email protected]> Pull request: #509 Approved by: smith
|
☀️ Test successful - travis |
fnichol
added a commit
that referenced
this pull request
May 17, 2016
This change is designed to make a Studio even more temporary and
ephemeral for build-related tasks. Now when performing a build using the
`hab-studio build` subcommand, a directory local to your current working
directory is created called `./results` which will have a copy of the
produces Habitat artifact on success.
Local artifact copy
-------------------
A `./results/` directory is now created in the same directory you
invoke `hab-studio build` or `hab-studio enter` from and contains a copy
of the produced Habitat artifact file. Because the parent directory of
`./results/` has been bind-mounted into the Studio's chroot, this means
the the `./results/` directory will appear locally outside the Studio
and will persist after a Studio has been torn down.
For example:
```
results
|-- core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
|-- last_build.env
`-- logs
`-- bzip2.2016-05-17-193809.log
```
Modifed build report
--------------------
Additionally a very build report (building on #509) is also written to
the `./results` directory as `./results/last_build.env`. The intended
user of this report is a build automation process, CI/CD environment,
etc. The format is shell-compatible variable assignments of the form:
```
<var>=<val>
```
Where `<var>` is a variable and `<val>` is its value, delimited with an
equals sign. The current contents of this build report are as follows:
* `pkg_origin` - the artifact origin, such as `core`
* `pkg_name` - the artifact name, such as `bzip2`
* `pkg_version` - the artifact version, such as `1.0.6`
* `pkg_release` - the artifact release, such as `20160517193810`
* `pkg_ident` - the artifact's package identifier, such as
`core/bzip2/1.0.6/20160517193810`
For example:
```
pkg_origin=core
pkg_name=bzip2
pkg_version=1.0.6
pkg_release=20160517193810
pkg_ident=core/bzip2/1.0.6/20160517193810
pkg_artifact=core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
```
**Note** that the order of these variables will not be guarenteed, only
that the variable names and their values will be present, one per line.
Any tooling which consume this report should take measures to not assume
any line ordering of the file's contents.
Build logs with hab-studio build
--------------------------------
This change also puts a session recording-style log (captured via the
`script(1)` program) in a `./results/logs` subdirectory.
Habitat plan.sh subdirectory default convention
-----------------------------------------------
This change also introduces a happy-path directory naming convention if
you choose to place your `plan.sh` and related files in a subdirectory
under your project's root. In short, simply call the directory
`habitat/` and you're good to go.
The `hab-plan-build.sh` program takes an argument as before which is a
path to a directory containing a `plan.sh` file, however on failure, it
will additionally check for `habitat/plan.sh` before giving up.
An example might help to clarify. Let's assume we are creating Habitat
packages for a Ruby application which exists in its own git repository
(not important, but only that the directory we're sitting in contains
the root of the application).
A simple "flat" style of arranging the Habitat-related files is:
```
.
|-- config
| `-- env.rb
|-- default.toml
|-- hooks
| `-- run
|-- lib
|-- plan.sh
`-- test
```
A "nested" style of arranging the Habitat-related files is:
```
.
|-- habitat
| |-- config
| | `-- env.rb
| |-- default.toml
| |-- hooks
| | `-- run
| `-- plan.sh
|-- lib
`-- test
```
Calling `hab-studio build` in the root of this project will produce
identical results without having to specify the `habitat/` path in the
"nested" style.
The same applies to non-application Plans such as software/library
Plans. There is no need for hooks, config, etc in these style packages
so most of the time it is simple enough to put the `plan.sh` in the root
of that project. However, the "nested" style also works here too. To
each, their own.
It should also be noted that calling the `build` program inside a Studio
(via `hab-studio enter`) also yields this behavior.
Signed-off-by: Fletcher Nichol <[email protected]>
fnichol
added a commit
that referenced
this pull request
May 18, 2016
This change is designed to make a Studio even more temporary and
ephemeral for build-related tasks. Now when performing a build using the
`hab-studio build` subcommand, a directory local to your current working
directory is created called `./results` which will have a copy of the
produces Habitat artifact on success.
Local artifact copy
-------------------
A `./results/` directory is now created in the same directory you
invoke `hab-studio build` or `hab-studio enter` from and contains a copy
of the produced Habitat artifact file. Because the parent directory of
`./results/` has been bind-mounted into the Studio's chroot, this means
the the `./results/` directory will appear locally outside the Studio
and will persist after a Studio has been torn down.
For example:
```
results
|-- core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
|-- last_build.env
`-- logs
`-- bzip2.2016-05-17-193809.log
```
Modifed build report
--------------------
Additionally a very build report (building on #509) is also written to
the `./results` directory as `./results/last_build.env`. The intended
user of this report is a build automation process, CI/CD environment,
etc. The format is shell-compatible variable assignments of the form:
```
<var>=<val>
```
Where `<var>` is a variable and `<val>` is its value, delimited with an
equals sign. The current contents of this build report are as follows:
* `pkg_origin` - the artifact origin, such as `core`
* `pkg_name` - the artifact name, such as `bzip2`
* `pkg_version` - the artifact version, such as `1.0.6`
* `pkg_release` - the artifact release, such as `20160517193810`
* `pkg_ident` - the artifact's package identifier, such as
`core/bzip2/1.0.6/20160517193810`
For example:
```
pkg_origin=core
pkg_name=bzip2
pkg_version=1.0.6
pkg_release=20160517193810
pkg_ident=core/bzip2/1.0.6/20160517193810
pkg_artifact=core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
```
**Note** that the order of these variables will not be guarenteed, only
that the variable names and their values will be present, one per line.
Any tooling which consume this report should take measures to not assume
any line ordering of the file's contents.
Build logs with hab-studio build
--------------------------------
This change also puts a session recording-style log (captured via the
`script(1)` program) in a `./results/logs` subdirectory.
Habitat plan.sh subdirectory default convention
-----------------------------------------------
This change also introduces a happy-path directory naming convention if
you choose to place your `plan.sh` and related files in a subdirectory
under your project's root. In short, simply call the directory
`habitat/` and you're good to go.
The `hab-plan-build.sh` program takes an argument as before which is a
path to a directory containing a `plan.sh` file, however on failure, it
will additionally check for `habitat/plan.sh` before giving up.
An example might help to clarify. Let's assume we are creating Habitat
packages for a Ruby application which exists in its own git repository
(not important, but only that the directory we're sitting in contains
the root of the application).
A simple "flat" style of arranging the Habitat-related files is:
```
.
|-- config
| `-- env.rb
|-- default.toml
|-- hooks
| `-- run
|-- lib
|-- plan.sh
`-- test
```
A "nested" style of arranging the Habitat-related files is:
```
.
|-- habitat
| |-- config
| | `-- env.rb
| |-- default.toml
| |-- hooks
| | `-- run
| `-- plan.sh
|-- lib
`-- test
```
Calling `hab-studio build` in the root of this project will produce
identical results without having to specify the `habitat/` path in the
"nested" style.
The same applies to non-application Plans such as software/library
Plans. There is no need for hooks, config, etc in these style packages
so most of the time it is simple enough to put the `plan.sh` in the root
of that project. However, the "nested" style also works here too. To
each, their own.
It should also be noted that calling the `build` program inside a Studio
(via `hab-studio enter`) also yields this behavior.
Signed-off-by: Fletcher Nichol <[email protected]>
thesentinels
pushed a commit
that referenced
this pull request
May 18, 2016
This change is designed to make a Studio even more temporary and
ephemeral for build-related tasks. Now when performing a build using the
`hab-studio build` subcommand, a directory local to your current working
directory is created called `./results` which will have a copy of the
produces Habitat artifact on success.
Local artifact copy
-------------------
A `./results/` directory is now created in the same directory you
invoke `hab-studio build` or `hab-studio enter` from and contains a copy
of the produced Habitat artifact file. Because the parent directory of
`./results/` has been bind-mounted into the Studio's chroot, this means
the the `./results/` directory will appear locally outside the Studio
and will persist after a Studio has been torn down.
For example:
```
results
|-- core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
|-- last_build.env
`-- logs
`-- bzip2.2016-05-17-193809.log
```
Modifed build report
--------------------
Additionally a very build report (building on #509) is also written to
the `./results` directory as `./results/last_build.env`. The intended
user of this report is a build automation process, CI/CD environment,
etc. The format is shell-compatible variable assignments of the form:
```
<var>=<val>
```
Where `<var>` is a variable and `<val>` is its value, delimited with an
equals sign. The current contents of this build report are as follows:
* `pkg_origin` - the artifact origin, such as `core`
* `pkg_name` - the artifact name, such as `bzip2`
* `pkg_version` - the artifact version, such as `1.0.6`
* `pkg_release` - the artifact release, such as `20160517193810`
* `pkg_ident` - the artifact's package identifier, such as
`core/bzip2/1.0.6/20160517193810`
For example:
```
pkg_origin=core
pkg_name=bzip2
pkg_version=1.0.6
pkg_release=20160517193810
pkg_ident=core/bzip2/1.0.6/20160517193810
pkg_artifact=core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
```
**Note** that the order of these variables will not be guarenteed, only
that the variable names and their values will be present, one per line.
Any tooling which consume this report should take measures to not assume
any line ordering of the file's contents.
Build logs with hab-studio build
--------------------------------
This change also puts a session recording-style log (captured via the
`script(1)` program) in a `./results/logs` subdirectory.
Habitat plan.sh subdirectory default convention
-----------------------------------------------
This change also introduces a happy-path directory naming convention if
you choose to place your `plan.sh` and related files in a subdirectory
under your project's root. In short, simply call the directory
`habitat/` and you're good to go.
The `hab-plan-build.sh` program takes an argument as before which is a
path to a directory containing a `plan.sh` file, however on failure, it
will additionally check for `habitat/plan.sh` before giving up.
An example might help to clarify. Let's assume we are creating Habitat
packages for a Ruby application which exists in its own git repository
(not important, but only that the directory we're sitting in contains
the root of the application).
A simple "flat" style of arranging the Habitat-related files is:
```
.
|-- config
| `-- env.rb
|-- default.toml
|-- hooks
| `-- run
|-- lib
|-- plan.sh
`-- test
```
A "nested" style of arranging the Habitat-related files is:
```
.
|-- habitat
| |-- config
| | `-- env.rb
| |-- default.toml
| |-- hooks
| | `-- run
| `-- plan.sh
|-- lib
`-- test
```
Calling `hab-studio build` in the root of this project will produce
identical results without having to specify the `habitat/` path in the
"nested" style.
The same applies to non-application Plans such as software/library
Plans. There is no need for hooks, config, etc in these style packages
so most of the time it is simple enough to put the `plan.sh` in the root
of that project. However, the "nested" style also works here too. To
each, their own.
It should also be noted that calling the `build` program inside a Studio
(via `hab-studio enter`) also yields this behavior.
Signed-off-by: Fletcher Nichol <[email protected]>
Pull request: #532
Approved by: reset
fnichol
added a commit
that referenced
this pull request
May 18, 2016
This change is designed to make a Studio even more temporary and
ephemeral for build-related tasks. Now when performing a build using the
`hab-studio build` subcommand, a directory local to your current working
directory is created called `./results` which will have a copy of the
produces Habitat artifact on success.
Local artifact copy
-------------------
A `./results/` directory is now created in the same directory you
invoke `hab-studio build` or `hab-studio enter` from and contains a copy
of the produced Habitat artifact file. Because the parent directory of
`./results/` has been bind-mounted into the Studio's chroot, this means
the the `./results/` directory will appear locally outside the Studio
and will persist after a Studio has been torn down.
For example:
```
results
|-- core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
|-- last_build.env
`-- logs
`-- bzip2.2016-05-17-193809.log
```
Modifed build report
--------------------
Additionally a very build report (building on #509) is also written to
the `./results` directory as `./results/last_build.env`. The intended
user of this report is a build automation process, CI/CD environment,
etc. The format is shell-compatible variable assignments of the form:
```
<var>=<val>
```
Where `<var>` is a variable and `<val>` is its value, delimited with an
equals sign. The current contents of this build report are as follows:
* `pkg_origin` - the artifact origin, such as `core`
* `pkg_name` - the artifact name, such as `bzip2`
* `pkg_version` - the artifact version, such as `1.0.6`
* `pkg_release` - the artifact release, such as `20160517193810`
* `pkg_ident` - the artifact's package identifier, such as
`core/bzip2/1.0.6/20160517193810`
For example:
```
pkg_origin=core
pkg_name=bzip2
pkg_version=1.0.6
pkg_release=20160517193810
pkg_ident=core/bzip2/1.0.6/20160517193810
pkg_artifact=core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
```
**Note** that the order of these variables will not be guarenteed, only
that the variable names and their values will be present, one per line.
Any tooling which consume this report should take measures to not assume
any line ordering of the file's contents.
Build logs with hab-studio build
--------------------------------
This change also puts a session recording-style log (captured via the
`script(1)` program) in a `./results/logs` subdirectory.
Habitat plan.sh subdirectory default convention
-----------------------------------------------
This change also introduces a happy-path directory naming convention if
you choose to place your `plan.sh` and related files in a subdirectory
under your project's root. In short, simply call the directory
`habitat/` and you're good to go.
The `hab-plan-build.sh` program takes an argument as before which is a
path to a directory containing a `plan.sh` file, however on failure, it
will additionally check for `habitat/plan.sh` before giving up.
An example might help to clarify. Let's assume we are creating Habitat
packages for a Ruby application which exists in its own git repository
(not important, but only that the directory we're sitting in contains
the root of the application).
A simple "flat" style of arranging the Habitat-related files is:
```
.
|-- config
| `-- env.rb
|-- default.toml
|-- hooks
| `-- run
|-- lib
|-- plan.sh
`-- test
```
A "nested" style of arranging the Habitat-related files is:
```
.
|-- habitat
| |-- config
| | `-- env.rb
| |-- default.toml
| |-- hooks
| | `-- run
| `-- plan.sh
|-- lib
`-- test
```
Calling `hab-studio build` in the root of this project will produce
identical results without having to specify the `habitat/` path in the
"nested" style.
The same applies to non-application Plans such as software/library
Plans. There is no need for hooks, config, etc in these style packages
so most of the time it is simple enough to put the `plan.sh` in the root
of that project. However, the "nested" style also works here too. To
each, their own.
It should also be noted that calling the `build` program inside a Studio
(via `hab-studio enter`) also yields this behavior.
Signed-off-by: Fletcher Nichol <[email protected]>
thesentinels
pushed a commit
that referenced
this pull request
May 18, 2016
This change is designed to make a Studio even more temporary and
ephemeral for build-related tasks. Now when performing a build using the
`hab-studio build` subcommand, a directory local to your current working
directory is created called `./results` which will have a copy of the
produces Habitat artifact on success.
Local artifact copy
-------------------
A `./results/` directory is now created in the same directory you
invoke `hab-studio build` or `hab-studio enter` from and contains a copy
of the produced Habitat artifact file. Because the parent directory of
`./results/` has been bind-mounted into the Studio's chroot, this means
the the `./results/` directory will appear locally outside the Studio
and will persist after a Studio has been torn down.
For example:
```
results
|-- core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
|-- last_build.env
`-- logs
`-- bzip2.2016-05-17-193809.log
```
Modifed build report
--------------------
Additionally a very build report (building on #509) is also written to
the `./results` directory as `./results/last_build.env`. The intended
user of this report is a build automation process, CI/CD environment,
etc. The format is shell-compatible variable assignments of the form:
```
<var>=<val>
```
Where `<var>` is a variable and `<val>` is its value, delimited with an
equals sign. The current contents of this build report are as follows:
* `pkg_origin` - the artifact origin, such as `core`
* `pkg_name` - the artifact name, such as `bzip2`
* `pkg_version` - the artifact version, such as `1.0.6`
* `pkg_release` - the artifact release, such as `20160517193810`
* `pkg_ident` - the artifact's package identifier, such as
`core/bzip2/1.0.6/20160517193810`
For example:
```
pkg_origin=core
pkg_name=bzip2
pkg_version=1.0.6
pkg_release=20160517193810
pkg_ident=core/bzip2/1.0.6/20160517193810
pkg_artifact=core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
```
**Note** that the order of these variables will not be guarenteed, only
that the variable names and their values will be present, one per line.
Any tooling which consume this report should take measures to not assume
any line ordering of the file's contents.
Build logs with hab-studio build
--------------------------------
This change also puts a session recording-style log (captured via the
`script(1)` program) in a `./results/logs` subdirectory.
Habitat plan.sh subdirectory default convention
-----------------------------------------------
This change also introduces a happy-path directory naming convention if
you choose to place your `plan.sh` and related files in a subdirectory
under your project's root. In short, simply call the directory
`habitat/` and you're good to go.
The `hab-plan-build.sh` program takes an argument as before which is a
path to a directory containing a `plan.sh` file, however on failure, it
will additionally check for `habitat/plan.sh` before giving up.
An example might help to clarify. Let's assume we are creating Habitat
packages for a Ruby application which exists in its own git repository
(not important, but only that the directory we're sitting in contains
the root of the application).
A simple "flat" style of arranging the Habitat-related files is:
```
.
|-- config
| `-- env.rb
|-- default.toml
|-- hooks
| `-- run
|-- lib
|-- plan.sh
`-- test
```
A "nested" style of arranging the Habitat-related files is:
```
.
|-- habitat
| |-- config
| | `-- env.rb
| |-- default.toml
| |-- hooks
| | `-- run
| `-- plan.sh
|-- lib
`-- test
```
Calling `hab-studio build` in the root of this project will produce
identical results without having to specify the `habitat/` path in the
"nested" style.
The same applies to non-application Plans such as software/library
Plans. There is no need for hooks, config, etc in these style packages
so most of the time it is simple enough to put the `plan.sh` in the root
of that project. However, the "nested" style also works here too. To
each, their own.
It should also be noted that calling the `build` program inside a Studio
(via `hab-studio enter`) also yields this behavior.
Signed-off-by: Fletcher Nichol <[email protected]>
Pull request: #532
Approved by: fnichol
fnichol
added a commit
that referenced
this pull request
May 18, 2016
This change is designed to make a Studio even more temporary and
ephemeral for build-related tasks. Now when performing a build using the
`hab-studio build` subcommand, a directory local to your current working
directory is created called `./results` which will have a copy of the
produces Habitat artifact on success.
Local artifact copy
-------------------
A `./results/` directory is now created in the same directory you
invoke `hab-studio build` or `hab-studio enter` from and contains a copy
of the produced Habitat artifact file. Because the parent directory of
`./results/` has been bind-mounted into the Studio's chroot, this means
the the `./results/` directory will appear locally outside the Studio
and will persist after a Studio has been torn down.
For example:
```
results
|-- core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
|-- last_build.env
`-- logs
`-- bzip2.2016-05-17-193809.log
```
Modifed build report
--------------------
Additionally a very build report (building on #509) is also written to
the `./results` directory as `./results/last_build.env`. The intended
user of this report is a build automation process, CI/CD environment,
etc. The format is shell-compatible variable assignments of the form:
```
<var>=<val>
```
Where `<var>` is a variable and `<val>` is its value, delimited with an
equals sign. The current contents of this build report are as follows:
* `pkg_origin` - the artifact origin, such as `core`
* `pkg_name` - the artifact name, such as `bzip2`
* `pkg_version` - the artifact version, such as `1.0.6`
* `pkg_release` - the artifact release, such as `20160517193810`
* `pkg_ident` - the artifact's package identifier, such as
`core/bzip2/1.0.6/20160517193810`
For example:
```
pkg_origin=core
pkg_name=bzip2
pkg_version=1.0.6
pkg_release=20160517193810
pkg_ident=core/bzip2/1.0.6/20160517193810
pkg_artifact=core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
```
**Note** that the order of these variables will not be guarenteed, only
that the variable names and their values will be present, one per line.
Any tooling which consume this report should take measures to not assume
any line ordering of the file's contents.
Build logs with hab-studio build
--------------------------------
This change also puts a session recording-style log (captured via the
`script(1)` program) in a `./results/logs` subdirectory.
Habitat plan.sh subdirectory default convention
-----------------------------------------------
This change also introduces a happy-path directory naming convention if
you choose to place your `plan.sh` and related files in a subdirectory
under your project's root. In short, simply call the directory
`habitat/` and you're good to go.
The `hab-plan-build.sh` program takes an argument as before which is a
path to a directory containing a `plan.sh` file, however on failure, it
will additionally check for `habitat/plan.sh` before giving up.
An example might help to clarify. Let's assume we are creating Habitat
packages for a Ruby application which exists in its own git repository
(not important, but only that the directory we're sitting in contains
the root of the application).
A simple "flat" style of arranging the Habitat-related files is:
```
.
|-- config
| `-- env.rb
|-- default.toml
|-- hooks
| `-- run
|-- lib
|-- plan.sh
`-- test
```
A "nested" style of arranging the Habitat-related files is:
```
.
|-- habitat
| |-- config
| | `-- env.rb
| |-- default.toml
| |-- hooks
| | `-- run
| `-- plan.sh
|-- lib
`-- test
```
Calling `hab-studio build` in the root of this project will produce
identical results without having to specify the `habitat/` path in the
"nested" style.
The same applies to non-application Plans such as software/library
Plans. There is no need for hooks, config, etc in these style packages
so most of the time it is simple enough to put the `plan.sh` in the root
of that project. However, the "nested" style also works here too. To
each, their own.
It should also be noted that calling the `build` program inside a Studio
(via `hab-studio enter`) also yields this behavior.
Signed-off-by: Fletcher Nichol <[email protected]>
thesentinels
pushed a commit
that referenced
this pull request
May 18, 2016
This change is designed to make a Studio even more temporary and
ephemeral for build-related tasks. Now when performing a build using the
`hab-studio build` subcommand, a directory local to your current working
directory is created called `./results` which will have a copy of the
produces Habitat artifact on success.
Local artifact copy
-------------------
A `./results/` directory is now created in the same directory you
invoke `hab-studio build` or `hab-studio enter` from and contains a copy
of the produced Habitat artifact file. Because the parent directory of
`./results/` has been bind-mounted into the Studio's chroot, this means
the the `./results/` directory will appear locally outside the Studio
and will persist after a Studio has been torn down.
For example:
```
results
|-- core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
|-- last_build.env
`-- logs
`-- bzip2.2016-05-17-193809.log
```
Modifed build report
--------------------
Additionally a very build report (building on #509) is also written to
the `./results` directory as `./results/last_build.env`. The intended
user of this report is a build automation process, CI/CD environment,
etc. The format is shell-compatible variable assignments of the form:
```
<var>=<val>
```
Where `<var>` is a variable and `<val>` is its value, delimited with an
equals sign. The current contents of this build report are as follows:
* `pkg_origin` - the artifact origin, such as `core`
* `pkg_name` - the artifact name, such as `bzip2`
* `pkg_version` - the artifact version, such as `1.0.6`
* `pkg_release` - the artifact release, such as `20160517193810`
* `pkg_ident` - the artifact's package identifier, such as
`core/bzip2/1.0.6/20160517193810`
For example:
```
pkg_origin=core
pkg_name=bzip2
pkg_version=1.0.6
pkg_release=20160517193810
pkg_ident=core/bzip2/1.0.6/20160517193810
pkg_artifact=core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
```
**Note** that the order of these variables will not be guarenteed, only
that the variable names and their values will be present, one per line.
Any tooling which consume this report should take measures to not assume
any line ordering of the file's contents.
Build logs with hab-studio build
--------------------------------
This change also puts a session recording-style log (captured via the
`script(1)` program) in a `./results/logs` subdirectory.
Habitat plan.sh subdirectory default convention
-----------------------------------------------
This change also introduces a happy-path directory naming convention if
you choose to place your `plan.sh` and related files in a subdirectory
under your project's root. In short, simply call the directory
`habitat/` and you're good to go.
The `hab-plan-build.sh` program takes an argument as before which is a
path to a directory containing a `plan.sh` file, however on failure, it
will additionally check for `habitat/plan.sh` before giving up.
An example might help to clarify. Let's assume we are creating Habitat
packages for a Ruby application which exists in its own git repository
(not important, but only that the directory we're sitting in contains
the root of the application).
A simple "flat" style of arranging the Habitat-related files is:
```
.
|-- config
| `-- env.rb
|-- default.toml
|-- hooks
| `-- run
|-- lib
|-- plan.sh
`-- test
```
A "nested" style of arranging the Habitat-related files is:
```
.
|-- habitat
| |-- config
| | `-- env.rb
| |-- default.toml
| |-- hooks
| | `-- run
| `-- plan.sh
|-- lib
`-- test
```
Calling `hab-studio build` in the root of this project will produce
identical results without having to specify the `habitat/` path in the
"nested" style.
The same applies to non-application Plans such as software/library
Plans. There is no need for hooks, config, etc in these style packages
so most of the time it is simple enough to put the `plan.sh` in the root
of that project. However, the "nested" style also works here too. To
each, their own.
It should also be noted that calling the `build` program inside a Studio
(via `hab-studio enter`) also yields this behavior.
Signed-off-by: Fletcher Nichol <[email protected]>
Pull request: #532
Approved by: fnichol
jtimberman
pushed a commit
that referenced
this pull request
Jun 12, 2016
It is desirable to have a simple machine parseable output file from a build so that it can be consumed in CD/CI systems. We need the source cache, the installed path, and the full path to the build artifact. Signed-off-by: jtimberman <[email protected]> Pull request: #509 Approved by: smith
jtimberman
pushed a commit
that referenced
this pull request
Jun 12, 2016
This change is designed to make a Studio even more temporary and
ephemeral for build-related tasks. Now when performing a build using the
`hab-studio build` subcommand, a directory local to your current working
directory is created called `./results` which will have a copy of the
produces Habitat artifact on success.
Local artifact copy
-------------------
A `./results/` directory is now created in the same directory you
invoke `hab-studio build` or `hab-studio enter` from and contains a copy
of the produced Habitat artifact file. Because the parent directory of
`./results/` has been bind-mounted into the Studio's chroot, this means
the the `./results/` directory will appear locally outside the Studio
and will persist after a Studio has been torn down.
For example:
```
results
|-- core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
|-- last_build.env
`-- logs
`-- bzip2.2016-05-17-193809.log
```
Modifed build report
--------------------
Additionally a very build report (building on #509) is also written to
the `./results` directory as `./results/last_build.env`. The intended
user of this report is a build automation process, CI/CD environment,
etc. The format is shell-compatible variable assignments of the form:
```
<var>=<val>
```
Where `<var>` is a variable and `<val>` is its value, delimited with an
equals sign. The current contents of this build report are as follows:
* `pkg_origin` - the artifact origin, such as `core`
* `pkg_name` - the artifact name, such as `bzip2`
* `pkg_version` - the artifact version, such as `1.0.6`
* `pkg_release` - the artifact release, such as `20160517193810`
* `pkg_ident` - the artifact's package identifier, such as
`core/bzip2/1.0.6/20160517193810`
For example:
```
pkg_origin=core
pkg_name=bzip2
pkg_version=1.0.6
pkg_release=20160517193810
pkg_ident=core/bzip2/1.0.6/20160517193810
pkg_artifact=core-bzip2-1.0.6-20160517193810-x86_64-linux.hart
```
**Note** that the order of these variables will not be guarenteed, only
that the variable names and their values will be present, one per line.
Any tooling which consume this report should take measures to not assume
any line ordering of the file's contents.
Build logs with hab-studio build
--------------------------------
This change also puts a session recording-style log (captured via the
`script(1)` program) in a `./results/logs` subdirectory.
Habitat plan.sh subdirectory default convention
-----------------------------------------------
This change also introduces a happy-path directory naming convention if
you choose to place your `plan.sh` and related files in a subdirectory
under your project's root. In short, simply call the directory
`habitat/` and you're good to go.
The `hab-plan-build.sh` program takes an argument as before which is a
path to a directory containing a `plan.sh` file, however on failure, it
will additionally check for `habitat/plan.sh` before giving up.
An example might help to clarify. Let's assume we are creating Habitat
packages for a Ruby application which exists in its own git repository
(not important, but only that the directory we're sitting in contains
the root of the application).
A simple "flat" style of arranging the Habitat-related files is:
```
.
|-- config
| `-- env.rb
|-- default.toml
|-- hooks
| `-- run
|-- lib
|-- plan.sh
`-- test
```
A "nested" style of arranging the Habitat-related files is:
```
.
|-- habitat
| |-- config
| | `-- env.rb
| |-- default.toml
| |-- hooks
| | `-- run
| `-- plan.sh
|-- lib
`-- test
```
Calling `hab-studio build` in the root of this project will produce
identical results without having to specify the `habitat/` path in the
"nested" style.
The same applies to non-application Plans such as software/library
Plans. There is no need for hooks, config, etc in these style packages
so most of the time it is simple enough to put the `plan.sh` in the root
of that project. However, the "nested" style also works here too. To
each, their own.
It should also be noted that calling the `build` program inside a Studio
(via `hab-studio enter`) also yields this behavior.
Signed-off-by: Fletcher Nichol <[email protected]>
Pull request: #532
Approved by: fnichol
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is desirable to have a simple machine parseable output file from a
build so that it can be consumed in CD/CI systems. We need the source
cache, the installed path, and the full path to the build artifact.
Signed-off-by: jtimberman [email protected]