Skip to content

Commit af495af

Browse files
sambhavsambhav
authored
Merge pull request cds-hooks#423 from buildpacks/release/lifecycle/0.12.0
Release/lifecycle/0.12.0
2 parents 21caae0 + d15c3ab commit af495af

File tree

6 files changed

+146
-3
lines changed

6 files changed

+146
-3
lines changed

‎content/docs/app-developer-guide/build-an-app.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -55,6 +55,12 @@ docker run --rm -p 8080:8080 sample-app
5555

5656
The app should now be running and accessible via [localhost:8080](http://localhost:8080).
5757

58+
## What about ARM apps?
59+
60+
Linux ARM image builds are now supported!
61+
62+
<a href="/docs/app-developer-guide/build-an-arm-app" class="button bg-blue">Linux ARM build guide</a>
63+
5864
## What about Windows apps?
5965

6066
Windows image builds are now supported!

‎content/docs/app-developer-guide/build-an-arm-app.md

Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
+++
2+
title="Build an ARM app"
3+
weight=2
4+
summary="The basics of taking your app from source code to runnable ARM image."
5+
+++
6+
7+
As of today, there are no CNB platforms (e.g. [pack][pack]) that support building ARM application images. In the following tutorial, we will be performing a build "manually", in that we will be performing a build by invoking the lifecycle directly.
8+
9+
### 1. Prepare your working directory
10+
11+
On your Linux ARM machine with a [docker][docker] daemon installed, prepare the following directory tree structure.
12+
13+
```bash
14+
tree ~/workspace/
15+
~/workspace/
16+
├── buildpacks
17+
│ └── samples_hello-world
18+
└── platform
19+
```
20+
21+
In addition, clone the [samples][samples] repository which will contain the application source code.
22+
23+
```bash
24+
# clone the repo
25+
git clone https://github.com/buildpacks/samples ~/workspace/samples
26+
```
27+
28+
### 2. Prepare the assets
29+
30+
Now we need to prepare assets that will be used during the build process.
31+
32+
First we download and extract the [lifecycle][lifecycle] release, compiled for ARM. Make sure to replace `<RELEASE-VERSION>` with a valid release version.
33+
34+
```bash
35+
# change to destination directory
36+
cd ~/workspace
37+
38+
# download and extract lifecycle
39+
curl -L https://github.com/buildpacks/lifecycle/releases/download/v<RELEASE-VERSION>/lifecycle-v<RELEASE-VERSION>+linux.arm64.tgz | tar xf -
40+
```
41+
42+
Next we make sure that our buildpack directory is structured in a way that the lifecycle will expect.
43+
44+
```bash
45+
# copy hello-world buildpack
46+
cp -R ~/workspace/samples/buildpacks/hello-world ~/workspace/buildpacks/samples_hello-world/0.0.1
47+
```
48+
49+
And finally we write the `order.toml` file that references the hello-world buildpack.
50+
51+
```bash
52+
cat > ~/workspace/order.toml <EOF
53+
[[order]]
54+
[[order.group]]
55+
id = "samples/hello-world"
56+
version = "0.0.1"
57+
optional = false
58+
EOF
59+
```
60+
61+
### 3. Build your app
62+
63+
Now we can build our app. For this example we will be using the docker CLI to invoke the lifecycle directly.
64+
65+
```bash
66+
# invoke the lifecycle
67+
docker run --rm \
68+
--mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
69+
--volume ~/workspace/lifecycle:/cnb/lifecycle \
70+
--volume ~/workspace/buildpacks:/cnb/buildpacks \
71+
--volume ~/workspace/samples/apps/bash-script:/workspace \
72+
--volume ~/workspace/platform:/platform \
73+
--mount type=bind,source=~/workspace/order.toml,target=/cnb/order.toml \
74+
--env CNB_PLATFORM_API=0.7 \
75+
ubuntu:bionic \
76+
/cnb/lifecycle/creator -log-level debug -daemon -run-image ubuntu:bionic hello-arm64
77+
```
78+
79+
### 4. Run it
80+
81+
```bash
82+
docker run --rm hello-arm64
83+
```
84+
85+
**Congratulations!**
86+
87+
The app image should now be built and stored on the docker daemon. You may perform `docker images` to verify.
88+
89+
[pack]: https://github.com/buildpacks/pack
90+
[docker]: https://docs.docker.com
91+
[samples]: https://github.com/buildpacks/samples
92+
[lifecycle]: https://github.com/buildpacks/lifecycle

‎content/docs/concepts/components/lifecycle/analyze.md

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,16 @@
11
+++
22
title="Analyze"
3-
weight=2
3+
weight=1
44
summary="Restores files that buildpacks may use to optimize the build and export phases."
55
+++
66

77
{{< param "summary" >}}
88

9+
Prior to `Platform API 0.7`, the `analyzer` was responsible for analyzing the metadata from the cache and the previously built image (if available) to determine what layers can or cannot be reused.
10+
This information is used during the `export` phase in order to avoid re-uploading unchanged layers.\
11+
Starting from `Platform API 0.7`, the `analyze` phase runs before the `detect` phase in order to validate registry access for all images that are used during the build as early as possible. In this way it provides faster failures for end users. The other responsibilities of the `analyzer` were moved to the `restorer`.\
12+
For more information, please see [this migration guide][platform-api-06-07-migration].
13+
914
### Exit Codes
1015

1116
| Exit Code | Result|
@@ -15,3 +20,5 @@ summary="Restores files that buildpacks may use to optimize the build and export
1520
| `12` | Buildpack API incompatibility error
1621
| `1-10`, `13-19` | Generic lifecycle errors
1722
| `30-39` | Analysis-specific lifecycle errors
23+
24+
[platform-api-06-07-migration]: https://buildpacks.io/docs/reference/spec/migration/platform-api-0.6-0.7/

‎content/docs/concepts/components/lifecycle/create.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
+++
22
title="Create"
33
weight=6
4-
summary="Runs detect, analyze, restore, build, and export in a single command."
4+
summary="Runs analyze, detect, restore, build, and export in a single command."
55
+++
66

77
{{< param "summary" >}}

‎content/docs/concepts/components/lifecycle/detect.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
+++
22
title="Detect"
3-
weight=1
3+
weight=2
44
summary="Finds an ordered group of buildpacks to use during the build phase."
55
+++
66

‎content/docs/reference/spec/migration/platform-api-0.6-0.7.md

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
+++
2+
title="Platform API 0.6 -> 0.7"
3+
+++
4+
5+
<!--more-->
6+
7+
This guide is most relevant to platform operators.
8+
9+
See the [spec release](https://github.com/buildpacks/spec/releases/tag/platform%2Fv0.7) for platform API 0.7 for the full list of changes and further details.
10+
11+
## Platform Operator
12+
13+
### Run the analyzer before the detector
14+
15+
The order of the lifecycle phases has been changed starting from Platform API 0.7.\
16+
The order before Platform API 0.7 was: detect, analyze, restore, build, and export.\
17+
The order starting from Platform API 0.7 is: analyze, detect, restore, build, and export.\
18+
The main reason for this change was to validate registry access for all images that are used during the build as early as possible. Starting from `Platform API 0.7`, it happens in the first lifecycle phase, as part of the `analyzer`, before running the `detector`. In this way it provides faster failures for end users.
19+
20+
As part of this change, a few flags were removed and others were added to some of the lifecycle phases.
21+
22+
The flags that were removed from the analyzer are:
23+
* `-cache-dir`
24+
* `-group`
25+
* `-skip-layers`
26+
27+
The flags that were added to the analyzer are:
28+
* `-previous-image`
29+
* `-run-image`
30+
* `-stack`
31+
* `-tag`
32+
33+
The flags that were added to the restorer are:
34+
* `-analyzed`
35+
* `-skip-layers`
36+
37+
The flag that was removed from the exporter is:
38+
* `-run-image`

0 commit comments

Comments
 (0)