https://pantsbuild.org/ logo
Join Slack
Powered by
Curious use case for pants… :thread: :slightly_sm...
# general
c
Curious use case for pants… 🧵 🙂
🧵 3
In the spirit of sharing what you can do with Pantsbuild… I just migrated a very odd project, whose purpose is to simply inject “artifical” artifact data into our CI/CD system, that doesn’t have a regular build pipeline. It’s basically a repo just listing releases, along with some instructions how they should be installed (manually, /shudder/).. so, what it does is less important, than how we managed to solve it, using Pants. So, some tidbits to follow..
First, we have a macro to make the most of the 
BUILD
files…
Copy code
def manual_release(
    version: str,
    *,
    filename: str | None = None,
    instructions: str | None = None,
    append_build_number: bool = True,
    append_build_number_sep: str | None = None,
    **kwargs,
):
    if append_build_number:
        if append_build_number_sep is None:
            append_build_number_sep = "-" if "-" not in version else "b_"
        version += append_build_number_sep + "${BUILD_NUMBER}"

    target(
        tags=[
            f"{tag}={value}"
            for tag, value in [
                ("filename", filename),
                ("instructions", instructions),
                ("version", version),
            ]
            if value is not None
        ],
        **kwargs,
    )
this simply turns it into a generic 
target
with some tags on it.
This is then used in 
<app name>/BUILD
files like:
Copy code
manual_release(
    "1.0.4",
    filename="deliverable-file",
    instructions=r"""
Some instructions here...
""",
)
And then the “build” script.. using some 
./pants --changed-since
and linting and various checks, boils down to this part, fishing out the relevant tagged target data:
Copy code
./pants --spec-files=releases.spec peek --exclude-defaults > release.json

echo -n "+ Release: "
jq -r 'include "utils"; .[]|publish_release' release.json | envsubst | tee releases_to_publish.txt

echo -n "+ Filename: "
jq -r 'include "utils"; .[]|translate_target|.attrs.filename' release.json | tee filename.txt

echo -n "+ Instructions: "
jq -r 'include "utils"; .[]|translate_target|.attrs.instructions' release.json | tee instructions.txt

echo filename.txt,instructions.txt > release_infos_to_publish.txt
Along with some 
jq
magic 😉
So, that concludes the show-and-tell.. how we used Pants simply for managing state.. sort of 😄
(n.b. the produced 
.txt
files are then picked up by later stages in the build pipeline for processing…)
b
"In the spirit of sharing what you can do with Pantsbuild…" Would you be interested in making this a blog post? Not necessarily hella longer, but just adding context for novices about the goal this serves for the team, and how Pants facilitates it? Could be an interesting mind-expanding example of how Pants can be used.
h
This is so cool!
❤️ 1
👍 1
There is an emerging concept of "git ops" - using git for things beyond revision control for source code, and I've been wondering about a similar "pants ops" - workflows that aren't exactly "build"
💯 1
c
Yeah, Pants is a great fit for that use case, I think..
I have another example, where we leverage custom targets (using the plugin api) to declare some meta data, that is then 
./pants compile-metadata
into a bunch of 
.yaml
files in the project. This to eliminate the need for manually maintaining the yaml data in favour of putting the data in BUILD file targets with all the benefits that comes with that.
something like this:
Copy code
$ cat svs_manifest.yaml _meta/build.yaml _meta/imports.yaml 
# DO NOT EDIT: This file was generated by `./pants compile-metadata` at 2021-12-13T14:21:19.678170.
build: _meta/build.yaml
import.all: _meta/imports.yaml
app.svs-pants-plugin:
  name: svs-pants-plugin
application_meta:
  account: 0
  name: svs-pants-plugin
  release_type: library
  language: python
# DO NOT EDIT: This file was generated by `./pants compile-metadata` at 2021-12-13T14:21:19.676371.
# Source: _meta/BUILD `svs_build` name='build'
name: pants-plugin
template: docker-lib
version: semantic
environment:
  PYTHON_RELEASE: '3.8'
  PYTHON_PATCH: '0'
# DO NOT EDIT: This file was generated by `./pants compile-metadata` at 2021-12-13T14:21:19.677324.
# Source: _meta/BUILD `svs_import_meta` name='imports'
repo: devops/meta-defaults
branch: fo_deployment
h
What are "all of the benefits"?
➕ 1
c
What are “all of the benefits”?
Compared to untyped (no schema) yaml files, the benefits are: • Type validation • Required field/values • Online help (on the CLI) • DRY-ness (dependencies allow generating a single value in multiple places in the output data) • Stable syntax (yaml being indentation sensitive, it is a common source of error, getting nested structures at the wrong level) • Lint/Check locally (when authoring the yaml files, besides using a yaml linter, any mistakes wouldn’t be reported until after push, with poor feedback to the developer.) • As we now have a “spec”, generating to a target format, it allows us to move forward easier simply adjusting how we generate the end result. • I’m sure there’s more, but this concept is just a few days old, so haven’t had the time to see all of the fruitions yet.. but none if these bullets are a minor thing! 😄
h
No that is all awesome! And stuff I had never thought of TBH
👍 1
5 Views
Open in Slack
PreviousNext
Powered by