Basic project setup

.github/CODEOWNERS

@@ -0,0 +1,2 @@
+# Default to requesting pull request reviews from the Heroku Languages team.
+* @heroku/languages

.github/dependabot.yml

@@ -0,0 +1,28 @@
+version: 2
+updates:
+  - package-ecosystem: "cargo"
+    directory: "/"
+    schedule:
+      interval: "monthly"
+    labels:
+      - "dependencies"
+      - "rust"
+      - "skip changelog"
+    groups:
+      # Note: The group order matters, since updates are assigned to the first matching group.
+      libcnb:
+        patterns:
+          - "libcnb*"
+          - "libherokubuildpack"
+      rust-dependencies:
+        update-types:
+          - "minor"
+          - "patch"
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "monthly"
+    labels:
+      - "dependencies"
+      - "github actions"
+      - "skip changelog"

.github/workflows/check_changelog.yml

@@ -0,0 +1,20 @@
+name: Check Changelog
+
+on:
+  pull_request:
+    types: [opened, reopened, labeled, unlabeled, synchronize]
+
+permissions:
+  contents: read
+
+jobs:
+  check-changelog:
+    runs-on: pub-hk-ubuntu-22.04-small # TODO: change to ubuntu-latest once repo is public
+    if: (!contains(github.event.pull_request.labels.*.name, 'skip changelog'))
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Check that CHANGELOG is touched
+        run: |
+          git fetch origin ${{ github.base_ref }} --depth 1 && \
+          git diff remotes/origin/${{ github.base_ref }} --name-only | grep CHANGELOG.md

.github/workflows/ci.yml

@@ -0,0 +1,67 @@
+name: CI
+
+on:
+  push:
+    # Avoid duplicate builds on PRs.
+    branches:
+      - main
+  pull_request:
+
+permissions:
+  contents: read
+
+env:
+  CARGO_TERM_COLOR: always
+
+jobs:
+  lint:
+    runs-on: pub-hk-ubuntu-22.04-small # TODO: change to ubuntu-latest once repo is public
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Update Rust toolchain
+        run: rustup update
+      - name: Rust Cache
+        uses: Swatinem/[email protected]
+      - name: Clippy
+        run: cargo clippy --all-targets --locked -- --deny warnings
+      - name: rustfmt
+        run: cargo fmt -- --check
+
+  unit-test:
+    runs-on: pub-hk-ubuntu-22.04-small # TODO: change to ubuntu-latest once repo is public
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Update Rust toolchain
+        run: rustup update
+      - name: Rust Cache
+        uses: Swatinem/[email protected]
+      - name: Run unit tests
+        run: cargo test --locked
+
+  integration-test:
+    runs-on: pub-hk-ubuntu-22.04-small # TODO: change to ubuntu-latest once repo is public
+    strategy:
+      fail-fast: false
+      matrix:
+        builder: ["builder:22", "builder:20"]
+    env:
+      INTEGRATION_TEST_CNB_BUILDER: heroku/${{ matrix.builder }}
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Install musl-tools
+        run: sudo apt-get install musl-tools --no-install-recommends
+      - name: Update Rust toolchain
+        run: rustup update
+      - name: Install Rust linux-musl target
+        run: rustup target add x86_64-unknown-linux-musl
+      - name: Rust Cache
+        uses: Swatinem/[email protected]
+      - name: Install Pack CLI
+        uses: buildpacks/github-actions/[email protected]
+      - name: Pull builder image
+        run: docker pull ${{ env.INTEGRATION_TEST_CNB_BUILDER }}
+      - name: Run integration tests
+        run: cargo test --locked -- --ignored --test-threads 5

.github/workflows/prepare-release.yml

@@ -0,0 +1,23 @@
+name: Prepare Buildpack Release
+
+on:
+  workflow_dispatch:
+    inputs:
+      bump:
+        description: "Bump"
+        required: true
+        default: "patch"
+        type: choice
+        options:
+          - major
+          - minor
+          - patch
+
+jobs:
+  prepare-release:
+    uses: heroku/languages-github-actions/.github/workflows/_buildpacks-prepare-release.yml@latest
+    with:
+      app_id: ${{ vars.LINGUIST_GH_APP_ID }}
+      bump: ${{ inputs.bump }}
+    secrets:
+      app_private_key: ${{ secrets.LINGUIST_GH_PRIVATE_KEY }}

.github/workflows/release.yml

@@ -0,0 +1,22 @@
+name: Release Buildpack
+
+on:
+  workflow_dispatch:
+    inputs:
+      dry_run:
+        description: Execute the release workflow but skip any steps that publish (for testing purposes)
+        type: boolean
+        default: false
+
+jobs:
+  release:
+    name: Release
+    uses: heroku/languages-github-actions/.github/workflows/_buildpacks-release.yml@latest
+    with:
+      app_id: ${{ vars.LINGUIST_GH_APP_ID }}
+      dry_run: ${{ inputs.dry_run }}
+    secrets:
+      app_private_key: ${{ secrets.LINGUIST_GH_PRIVATE_KEY }}
+      cnb_registry_token: ${{ secrets.CNB_REGISTRY_RELEASE_BOT_GITHUB_TOKEN }}
+      docker_hub_user: ${{ secrets.DOCKER_HUB_USER }}
+      docker_hub_token: ${{ secrets.DOCKER_HUB_TOKEN }}

.gitignore

@@ -3,12 +3,11 @@
 debug/
 target/
 
-# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
-# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
-Cargo.lock
-
 # These are backup files generated by rustfmt
 **/*.rs.bk
 
 # MSVC Windows builds of rustc generate these, which store debugging information
 *.pdb
+
+# IDE
+.idea

CHANGELOG.md

@@ -0,0 +1,8 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]

CODE_OF_CONDUCT.md

@@ -0,0 +1,105 @@
+# Salesforce Open Source Community Code of Conduct
+
+## About the Code of Conduct
+
+Equality is a core value at Salesforce. We believe a diverse and inclusive
+community fosters innovation and creativity, and are committed to building a
+culture where everyone feels included.
+
+Salesforce open-source projects are committed to providing a friendly, safe, and
+welcoming environment for all, regardless of gender identity and expression,
+sexual orientation, disability, physical appearance, body size, ethnicity, nationality,
+race, age, religion, level of experience, education, socioeconomic status, or
+other similar personal characteristics.
+
+The goal of this code of conduct is to specify a baseline standard of behavior so
+that people with different social values and communication styles can work
+together effectively, productively, and respectfully in our open source community.
+It also establishes a mechanism for reporting issues and resolving conflicts.
+
+All questions and reports of abusive, harassing, or otherwise unacceptable behavior
+in a Salesforce open-source project may be reported by contacting the Salesforce
+Open Source Conduct Committee at [email protected].
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of gender
+identity and expression, sexual orientation, disability, physical appearance,
+body size, ethnicity, nationality, race, age, religion, level of experience, education,
+socioeconomic status, or other similar personal characteristics.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy toward other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Personal attacks, insulting/derogatory comments, or trolling
+* Public or private harassment
+* Publishing, or threatening to publish, others' private information—such as
+  a physical or electronic address—without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+* Advocating for or encouraging any of the above behaviors
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned with this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project email
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the Salesforce Open Source Conduct Committee
+at [email protected]. All complaints will be reviewed and investigated
+and will result in a response that is deemed necessary and appropriate to the
+circumstances. The committee is obligated to maintain confidentiality with
+regard to the reporter of an incident. Further details of specific enforcement
+policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership and the Salesforce Open Source Conduct
+Committee.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][contributor-covenant-home],
+version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html.
+It includes adaptions and additions from [Go Community Code of Conduct][golang-coc],
+[CNCF Code of Conduct][cncf-coc], and [Microsoft Open Source Code of Conduct][microsoft-coc].
+
+This Code of Conduct is licensed under the [Creative Commons Attribution 3.0 License][cc-by-3-us].
+
+[contributor-covenant-home]: https://www.contributor-covenant.org (https://www.contributor-covenant.org/)
+[golang-coc]: https://golang.org/conduct
+[cncf-coc]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md
+[microsoft-coc]: https://opensource.microsoft.com/codeofconduct/
+[cc-by-3-us]: https://creativecommons.org/licenses/by/3.0/us/

CONTRIBUTING.md

@@ -0,0 +1,74 @@
+# Contributing Guide For Heroku's Apt Buildpack
+
+This page lists the operational governance model of this project, as well as the recommendations and requirements for how to best contribute to `heroku/buildpacks-apt`. We strive to obey these as best as possible. As always, thanks for contributing – we hope these guidelines make it easier and shed some light on our approach and processes.
+
+# Governance Model
+
+## Salesforce Sponsored
+
+The intent and goal of open sourcing this project is to increase the contributor and user base. However, only Salesforce employees will be given `admin` rights and will be the final arbitrars of what contributions are accepted or not.
+
+# Issues, requests & ideas
+
+Use GitHub Issues page to submit issues, enhancement requests and discuss ideas.
+
+### Bug Reports and Fixes
+-  If you find a bug, please search for it in the [Issues](https://github.com/heroku/buildpacks-apt/issues), and if it isn't already tracked,
+   [create a new issue](https://github.com/heroku/buildpacks-apt/issues/new). Fill out the "Bug Report" section of the issue template. Even if an Issue is closed, feel free to comment and add details, it will still
+   be reviewed.
+-  Issues that have already been identified as a bug (note: able to reproduce) will be labelled `bug`.
+-  If you'd like to submit a fix for a bug, [send a Pull Request](#creating_a_pull_request) and mention the Issue number.
+-  Include tests that isolate the bug and verifies that it was fixed.
+
+### New Features
+-  If you'd like to add new functionality to this project, describe the problem you want to solve in a [new Issue](https://github.com/heroku/buildpacks-apt/issues/new).
+-  Issues that have been identified as a feature request will be labelled `enhancement`.
+-  If you'd like to implement the new feature, please wait for feedback from the project
+   maintainers before spending too much time writing the code. In some cases, `enhancement`s may
+   not align well with the project objectives at the time.
+
+### Tests, Documentation, Miscellaneous
+-  If you'd like to improve the tests, you want to make the documentation clearer, you have an
+   alternative implementation of something that may have advantages over the way its currently
+   done, or you have any other change, we would be happy to hear about it!
+-  If its a trivial change, go ahead and [send a Pull Request](#creating_a_pull_request) with the changes you have in mind.
+-  If not, [open an Issue](https://github.com/heroku/buildpacks-apt/issues/new) to discuss the idea first.
+
+If you're new to our project and looking for some way to make your first contribution, look for
+Issues labelled `good first contribution`.
+
+# Contribution Checklist
+
+- [x] Clean, simple, well styled code
+- [x] Commits should be atomic and messages must be descriptive. Related issues should be mentioned by Issue number.
+- [x] Comments
+    - Module-level & function-level comments.
+    - Comments on complex blocks of code or algorithms (include references to sources).
+- [x] Tests
+    - The test suite, if provided, must be complete and pass
+    - Increase code coverage, not versa.
+    - Use any of our testkits that contains a bunch of testing facilities you would need. For example: `import com.salesforce.op.test._` and borrow inspiration from existing tests.
+- [x] Dependencies
+    - Minimize number of dependencies.
+    - Prefer Apache 2.0, BSD3, MIT, ISC and MPL licenses.
+- [x] Reviews
+    - Changes must be approved via peer code review
+
+# Creating a Pull Request
+
+1. **Ensure the bug/feature was not already reported** by searching on GitHub under Issues.  If none exists, create a new issue so that other contributors can keep track of what you are trying to add/fix and offer suggestions (or let you know if there is already an effort in progress).
+3. **Clone** the forked repo to your machine.
+4. **Create** a new branch to contain your work (e.g. `git br fix-issue-11`)
+4. **Commit** changes to your own branch.
+5. **Push** your work back up to your fork. (e.g. `git push fix-issue-11`)
+6. **Submit** a Pull Request against the `main` branch and refer to the issue(s) you are fixing. Try not to pollute your pull request with unintended changes. Keep it simple and small.
+7. **Sign** the Salesforce CLA (you will be prompted to do so when submitting the Pull Request)
+
+> **NOTE**: Be sure to [sync your fork](https://help.github.com/articles/syncing-a-fork/) before making a pull request.
+
+
+# Code of Conduct
+Please follow our [Code of Conduct](CODE_OF_CONDUCT.md).
+
+# License
+By contributing your code, you agree to license your contribution under the terms of our project [LICENSE](LICENSE.txt) and to sign the [Salesforce CLA](https://cla.salesforce.com/sign-cla)