Updated build output

[schneems]

This is a proposed output and a spike on some APIs. For the sake of not having to re-edit the PR description, I'll post updates on the output below.

Links

This PR is the result of quite a long process of revising the build output started around April 18th. Unfortunately, the documentation for those pieces is internal, but towards the end, I hope to release some formalized/finalized version.

Primary documents:

• Reverse timeline of build output a chronological ordering of events regarding the build output. I started this doc on April 24 which as of today is 36 working days accounting for hackweek (5 days), my 10 year anniversary (5 days), and weekends (18 days). I've made 19 entries or a little under an entry every two days that I've worked on this project. Of all the documents I've created, this has been the most useful.
• Build output spec (in progress) and related output spike which were used to generate the initial output we were settled on implementing.
• CNB Build output META - COIL a table-of-contents of sorts for the larger project.

Miscellaneous supporting documents:

• Problems Values Stakeholders Possibilities Evaluation - Logging.
• literature review.
• Why don't animations work in build outputs? animations can be simulated by using codes to delete and re-write characters over again. This works with the CLI but not via git push heroku, and the doc details an exploration into the details of why.
• CNB build output implementer problems.
• Ruby CNB build output for getting started guide 2023-04-18.
• Historical: 2020/10/09 RFC: Heroku CNB Logging Style.
• Hackweek team docs.
• Node.js CNB Output Thoughts - Josh Lewis.
• build output notes random assorted thoughts.
• CNB build output actions a list of actionable activities for anyone who wants to participate in the exploration.
• CLI Output Examples for Other SF Products.
• 2023-05-15 Output spike (Ruby build) replaced by output spike.
• CNB build output - User Problem collection.
• Ruby Classic build output for getting started guide 2023-04-18.

Work item: GUS-W-13115766

[schneems]

2023-06-28

Screenshot:

Raw output logs with no color:

# Heroku Ruby Buildpack

- Ruby version `3.1.3` from `default`
  - Installing [------] (5.577s)
- Bundler version `2.4.5` from `default`
- Bundle install
  - Running `BUNDLE_BIN="/layers/heroku_ruby/gems/bin" BUNDLE_CLEAN="1" BUNDLE_DEPLOYMENT="1" BUNDLE_GEMFILE="/workspace/Gemfile" BUNDLE_PATH="/layers/heroku_ruby/gems" BUNDLE_WITHOUT="development:test" bundle install`

      Fetching gem metadata from https://rubygems.org/..
      Fetching rake 13.0.6
      Installing rake 13.0.6
      Using bundler 2.4.5
      Fetching rack 2.2.3
      Fetching webrick 1.7.0
      Installing webrick 1.7.0
      Installing rack 2.2.3
      Bundle complete! 3 Gemfile dependencies, 4 gems now installed.
      Gems in the groups 'development' and 'test' were not installed.
      Bundled gems are installed into `/layers/heroku_ruby/gems`

  - Done (6.637s)
- Setting default processes(es)
  - Detecting gems
  - Running `bundle list` [-] (0.243s)
  - Detected rack app (`rack` gem and `config.ru` at root of application)
- Rake assets install
  - Cannot run rake tasks (no Rakefile)
  ! Help: Add `Rakefile` to your project to enable
- Done (finished in 13.572s)

[schneems]

i guess i was looking for a design that mapped more to specific UX language/terminology.

One of the hardest things in computer science. I'm open to suggestions. I wanted to start with a broad suite of tools and get more specific over time. The say_with_details is one example there where I found I kept having to build_output::fmt::details again and again, and it made sense to have a helper API. Some of the argument names are slightly suggestive like build_output::section() takes a topic argument to suggest a noun rather than a verb.

I'm happy to brainstorm/sketch either naming or ideas in person or async. I had considered something like encoding a set of known/approved verbs i.e. installing/creating/downloading etc. to standardize on some of the languages and also give us a very consistent visual output, however, at this stage didn't want to be overly restrictive