This repo has moved to https://github.com/heroku/buildpacks-node.
Cloud Native Buildpacks are buildpacks that turn source code into OCI images. They follow a 4-step process (detect, analyze, build, and export) that outputs an image. The spec can be read about in detail here.
Using brew
(assuming development is done on MacOS), install pack
.
brew tap buildpack/tap
brew install pack
If you're using Windows or Linux, follow instructions here.
This buildpack uses shpec
for unit tests, so to run them locally, you'll need to install the package.
curl -sLo- http://get.bpkg.sh | bash
bpkg install rylnd/shpec
Right now, we are prototyping with a local version of the buildpack. Clone it to your machine.
git clone git@github.com:heroku/nodejs-engine-buildpack.git
Using pack, you're ready to create an image from the buildpack and source code. You will need to add flags that point to the path of the buildpack (--buildpack
) and the path of the source code (--path
).
cd nodejs-engine-buildpack
pack build TEST_IMAGE_NAME --buildpack ../nodejs-engine-buildpack --path ../TEST_REPO_PATH
The buildpack uses a Golang binary to parse the engine versions from the package.json
. It's better to create the binaries once locally, so they don't have to be downloaded and rebuilt with every build.
make build
This builds the binaries specific for the Docker image. The binaries are in the .gitignore
, so they won't be committed or ever exist in the remote source code.
If you need them for a MacOS, run:
make build-local
The complete test suite needs Docker to run. Make sure to install Docker first.
make test
If you want to run individual test suites, that's available too.
Unit Tests
To run the tests on the local host, make sure shpec
is installed.
make unit-test
Binary Tests
make binary-tests
Running the shpec
aren't ideal since the test scripts read and write to the local buildpack directory, so Docker may be preferred.
As suggested above, install Docker. Next, run the tests with the Make script:
make docker-unit-test
To debug, make changes from the code and rerun with the make command. To see what is happening, I suggest wrapping code blocks in question with set -x
/set +x
. It would look like this in the shpec file:
set -x
it "creates a toolbox.toml"
install_or_reuse_toolbox "$layers_dir/toolbox"
assert file_present "$layers_dir/toolbox.toml"
end
set +x
- Open a pull request.
- Make update to
CHANGELOG.md
undermain
with a description (PR title is fine) of the change, the PR number and link to PR. - Let the tests run on CI. When tests pass and PR is approved, the branch is ready to be merged.
- Merge branch to
main
.
Note: if you're not a contributor to this project, a contributor will have to make the release for you.
- Create a new branch (ie.
1.14.2-release
). - Update the version in the
buildpack.toml
. - Move the changes from
main
to a new header with the version and date (ie.1.14.2 (2020-02-30)
) in theCHANGELOG.md
. - Open a pull request.
- Let the tests run on CI. When tests pass and PR is approved, the branch is ready to be merged.
- Merge branch to
main
on GitHub. - Pull down
main
to local machine. - Tag the current
main
with the version. (git tag v1.14.2
) - Push up to GitHub. (
git push origin main --tags
) CI will run the suite and create a new release on successful run.
- buildpacks: provide framework and a runtime for source code. Read more here.
- OCI image: OCI (Open Container Initiative) is a project to create open sourced standards for OS-level virtualization, most importantly in Linux containers.