hephaestus 0.8.12.2 → 0.8.13

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 946513d5bfb959191872e0404f6eb0c95c4a6d4ded918425926ba0ca24f09dce
-  data.tar.gz: 0524cf36eb6e3717eb1c1b7fab0de51438cbce348b0882a77e50422d5c25747a
+  metadata.gz: f10ca0de88c450f5e8febca532d785bb3e0b9ae1392e84a89e5bc69822936bf4
+  data.tar.gz: 5558246e1b43416722c74d86f35527b39894834524bb863c9cc7380233b661c5
 SHA512:
-  metadata.gz: 15f88a25cfea5f83d2fb5ac629d163ab2d8b1205bc3b5a99cf38282b8628cac6da86a31f68c99e4e9eb0511e6a5f270ce562aada76e76db9eebf31a2f25073aa
-  data.tar.gz: 4271659d3c4302dcfa5cb991b8b9c01f20a8d2e8d13b3b554cfea8a79417117ee86ee2228188984bc1a78b7f42e5a81325386ebade0714c32dd14a7d8a5168c0
+  metadata.gz: c38a22b9ac3409157e42f26aea6b82ea3b488c984b43e18918c8d4cf12aee16ec446fad81aa0d04cecad9ad5676130e4cc0990605d8502f2131af37e3d44d152
+  data.tar.gz: 04aa1224bad239a6f7ef662d1f00a61ffb0a560ab882472e7afcad07f820600f7f3e6f2aa70ef639338abfa5264f6544b99e096f75f0b4922c79425a77598ed9

data/CHANGELOG.md

@@ -1,3 +1,10 @@
+# [v0.8.13] - 17-12-2024
+## What's Changed
+* Move content to clio by @gjtorikian in https://github.com/yettoapp/hephaestus/pull/99
+* Remove outro, point to Clio by @gjtorikian in https://github.com/yettoapp/hephaestus/pull/100
+
+
+**Full Changelog**: https://github.com/yettoapp/hephaestus/compare/v0.8.12.2...v0.8.13
 # [v0.8.12.2] - 17-12-2024
 ## What's Changed
 * Fixups by @gjtorikian in https://github.com/yettoapp/hephaestus/pull/97

data/README.md

@@ -33,180 +33,6 @@ This way you can wipe the dir and quickly iterate on new changes.
 
 If you're having trouble connecting to the Internet, you can set `HEPHAESTUS_NO_EXTERNAL=1`.
 
-## Building upon the base
-
-Most of the files which Hephaestus creates for you shouldn't need much modification. The information below is part-informative, part-guidelines on how to extend the generated code for your specific plug.
-
-### Controllers
-
-#### `ApplicationController`
-
-Your application controller inherits from `Hephaestus::ApplicationController`, and handles the basics of request/response cycles. Two common callbacks to add here are:
-
-- `before_action :set_request_span_context`, which lets you add data to the `OpenTelemetry` trace before a request occurs
-- `after_action :set_response_span_context`, similarly, lets you add to the trace after the response is sent
-
-For examples on how to integrate with these, check out `plug-email`.
-
-#### `SettingsController`
-
-Typically, your settings inherit directly from Hephaestus. We'll discuss more about how this works in `routes.rb`. Either way, you'll define two files:
-
-- `app/views/settings/new.json.jbuilder`
-- `app/views/settings/edit.json.jbuilder`
-
-Define the settings UI in these files. See `plug-email` for an example of a settings page with no customizations.
-
-However, for multi-step plugs, it's common to expect customized steps. If you'd like to extend the settings controller, create a file with one of two methods:
-
-- `new`
-- `edit`
-
-You only need to define these methods if you're actually overriding the action—often, this only means `edit`. If you do define methods in this controller, remember to add `before_action :ensure_json_request` at the top. For examples on settings pages which have _some_ customization, see `plug-github` and `plug-linear`. For an example of a totally custom settings page, see `plug-zendesk`.
-
-#### `AppController`
-
-The logic to communicate with your platform sits in `AppController`. Every plug is unique, so the requirements for your platform varies!
-
-At a minimum, though, you should place all the logic which authenticates requests in the `Authable` concern. See `plug-github` and `plug-linear` for practical examples.
-
-#### `YettoController`
-
-Place the logic which receives webhooks from Yetto in the `YettoController`. This controller must `include Hephaestus::ValidatesFromYetto`, and must define `before_action :from_yetto?`. Beyond that, you can respond to events as they come in, and fire jobs to perform the actions your platform needs to integrate with Yetto.
-
-### Jobs
-
-Jobs are at the heart of plugs, because they perform time-sensitive work asynchronously. Since Hephaestus already creates an `ApplicationJob` which inherits from `Hephaestus::ApplicationJob`, there isn't much else you need to do, other than define your jobs.
-
-Whenever you need to integrate with Yetto, just pass the appropriate arguments to `Hephaestus::UpdateYettoJob`.
-
-The bulk of your plug logic should exist within these jobs. Keep the controllers as place to authenticate incoming requests and respond with appropriate status codes.
-
-### Constants
-
-Place any and all constants in the file called `lib/constants.rb`.
-
-Note that Hepheastus provides several convenience methods and constants for you. These are:
-
-- `plug_shortname`: the downcased version of the plug (e.g., `Slack => slack`, `GitHub => github`)
-- `plug_name`: The proper name of the plug (e.g., `Slack`, `GitHub`)
-- `plug_url`: The plug's URL (e.g., `email{.plugs.yetto.app,.plugs.yetto.dev,.ngrok.io}`)
-
-### Application Configuration
-
-The typical Rails' environment configs (`config/environments/{development.rb,test.rb,production.rb}`) are managed by Hephaestus. However, any plug can define their own environment files as well. These are added after Hephaestus' default configuration.
-
-The `test.rb` file in `plug-email` provides an example of this.
-
-#### Upgrading Rails
-
-Upgrading Rails always introduces breaking changes, even between minor releases. To ensure that a plug still works after a Rails upgrade, first, add
-
-```ruby
-rails "x"
-```
-
-to your plug's Gemfile (where `"x"` is the new Rails version.) Note that this means plugs can run Rails versions independently of what Hephaestus provides (although variance is not recommended, it can help during the upgrade process).
-
-Next, call `rails app:update:configs`. You can pretty much ignore every changed file, except the one that starts with `new_framework_defaults_`. Use these values to slowly reintroduce the new configuration changes, as described in [the Rails documentation](https://guides.rubyonrails.org/v8.0/upgrading_ruby_on_rails.html#configure-framework-defaults).
-
-### Integrating the Plug with the Engine
-
-There are certain times where the child application needs to "inject" data into Hephaestus. These are typically customizations that are unique to the plug. Place these customizations in `config/application.rb`, inside of an `initializer :engines_blank_point do` block.
-
-At a minimum, you'll need to define your plug's API version, and the version of the Yetto API it's communicating with:
-
-```ruby
-initializer :engines_blank_point do
-  config.yetto_api_version = "2023-03-06"
-  config.plug_api_version = "2023-03-06"
-end
-```
-
-You can also define several other customizations:
-
-- `config.tracing_body_filters`: use this to scrub out any sensitive data coming in from your platform, to prevent it from leaking in our metrics aggregator. See the override in `plug-email` for an example. The default is to simply log everything (after running it through [Rails' `ParameterFilter`](https://api.rubyonrails.org/v7.1/classes/ActiveSupport/ParameterFilter.html), of course), which may not be a good idea!
-- `config.enhance_update_yetto_job`: use this to include any plug-specific logic which needs to occur as part of issuing calls to the Yetto API
-
-For an example of both these customizations, see `plug-email`.
-
-There's also middleware you can use to protect any endpoint with an OpenAPI schema. To do so, add:
-
-```ruby
-require "hephaestus/middleware/openapi_validation"
-config.middleware.use(Hephaestus::Middleware::OpenapiValidation, match_path: "/app/2023-03-06/path/", limit_methods_to: ["POST"], spec: Rails.root.join("lib/schemas/path/2023-03-06/openapi.json"))
-```
-
-In this example, any `POST` to `match_path` is protected by the OpenAPI `spec` provided.
-
-### Services
-
-Place any HTTP communication necessary to communicate with your platform in this directory. All other code should which communicates to your plug should rely on methods defined in this file.
-
-See any of the plugs for an example of how to define this interaction, particularly with `httpsensible`.
-
-### Routes
-
-If you do not have any custom actions to perform in the settings controller, define your settings pages as:
-
-```ruby
-# you must always include this line when referring to `hephaestus_settings`
-HephaestusSettingsController = Hephaestus::SettingsController
-
-get "/api/#{Rails.application.config.plug_api_version}/settings", to: "hephaestus_settings#new"
-get "/api/#{Rails.application.config.plug_api_version}/settings/:organization_id/:inbox_id/:plug_installation_id/edit", to: "hephaestus_settings#edit"
-```
-
-Otherwise, be sure to refer to `hephaestus_settings` only for any default settings related actions:
-
-```ruby
-# you must always include this line when referring to `hephaestus_settings`
-HephaestusSettingsController = Hephaestus::SettingsController
-
-get "/api/#{Rails.application.config.plug_api_version}/settings", to: "hephaestus_settings#new"
-get "/api/#{Rails.application.config.plug_api_version}/settings/:organization_id/:inbox_id/:plug_installation_id/edit", to: "settings#edit"
-```
-
-Otherwise, you can add any other routes your plug needs to `config/routes.rb`.
-
-### Launching the server
-
-First, you'll note that you have a `script/ngrok` file, which launches an ngrok server at `https://${hostname}-plug-app.ngrok.io`, which maps locally to `http://localhost:6661`. Setting up ngrok can be essential when testing the platform locally for the first time. (Keep in mind that you still need to run `script/server` to actually start the local server—this is just to help facilitate communication with the platform.)
-
-### Setting up routes
-
-You should probably open up config/routes.rb to make modifications to any incoming (from the platform) or outgoing (for Yetto) HTTP flows.
-
-### Defining settings
-
-Next, you'll want to open `app/views/settings/new.json.jbuilder` and modify the JSON structure of the Settings form page users will see when they first install the plug. Note that this adheres to a strict schema.
-
-### Accepting events
-
-After a user submits a plug installation on the Yetto side, it'll send a POST payload to `/api/:version/:event/:record_type`--for example, `/api/2023-03-06/after/plug_installation`. Open up the `yetto_controller.rb` file and decide what happens next!
-
-### Creating services
-
-Any code which communicates with the third party should be placed in the `app/services` directory. A generic HTTP service is included.
-
-### Writing tests
-
-In addition to writing tests for your plug interacting with its platform, many of your tests will also need to cover your plug's interaction with Yetto.
-
-Writing these tests well comes with time; it's not an easy thing to cover in a pithy paragraph. Regardless, here's a bit of hopefully helpful advice.
-
-Be sure to tests requests before _and_ after they occur. Typically, this takes the form of a `stub_request` and `assert_requested`. Similarly, be sure to:
-
-- `include Hephaestus::Webmocks::SlackWebmock` whenever a plug action is expected to error out to Slack
-- `include Hephaestus::Webmocks::YettoWebmock` whenever a plug needs to issue a request to Yetto
-
-Use `include Hephaestus::API::TestHelpers` whenever you need to write a test which either
-
-- match `"/#{plug_shortname}` routes (by issuing calls to `plug`). These are routes which your external server is calling into.
-- match `/api` routes (by issuing calls to `api`). These are routes which Yetto is calling into.
-
-For examples on when and how to use these methods, see `plug-github`.
-
 ## Acknowledgements
 
 The template generation for this project was heavily based on [thoughtbot/suspenders](https://github.com/thoughtbot/suspenders).

data/lib/hephaestus/generators/app_generator.rb

@@ -247,37 +247,11 @@ module Hephaestus
     def outro
       say(<<~OUTPUT)
 
-        #{set_color("Congratulations!", :green)} You just made a Yetto plug.
+        #{set_color("Congratulations! You just made a Yetto plug.", :green)}
 
-        You'll need to `cd #{ARGV.first}` and run the following commands--I can't do it for you!
+        You'll need to `cd #{shell.base.result_dir}` and run some more commands--I can't do it for you!
 
-        * `bin/rails credentials:edit --environment development`
-
-        #{set_color("WAIT!", :red)} After running this command, note that Rails credited a file called development.key in the config/credentials directory.
-        Store this in 1Password, then change the .env file to use this value. Generate keys for staging/production, too:
-
-        * `bin/rails credentials:edit --environment staging`
-          `bin/rails credentials:edit --environment production`
-
-        Store this in 1Password too; you don't need the .env file for staging/production.
-
-        For `YETTO_SIGNING_SECRET` and `YETTO_PLUG_ID`, you'll need to generate those values yourself.
-
-        Then, try running `bin/rails c` to ensure that everything was set up correctly.
-        Running `rake test` is also a good idea.
-
-        #{set_color("Also, after pushing to GitHub:", :yellow)}
-
-        * Set `settings/branches` to protect `production`
-          * ✅ Require status checks to pass before merging
-          * 🖊️ Status checks that are required: `ruby / test_without_services`, `docker / test-build`, `ruby / brakeman`, `ruby / bundle-audit`.
-
-            You can only set those 👆 after you've opened the first PR on GitHub. Crazy, I know!!
-            But, doing so is *essential* for automerge to function properly.
-
-        * In `/settings`:
-          * ✅ Allow auto-merge
-          * ✅ Automatically delete head branches
+        Check out the appropriate documentation on Clio for more information: engineering/plugs/building.md
       OUTPUT
     end
 

data/lib/hephaestus/version.rb

@@ -2,7 +2,7 @@
 # frozen_string_literal: true
 
 module Hephaestus
-  VERSION = "0.8.12.2"
+  VERSION = "0.8.13"
   RAILS_VERSION = ">= 8.0"
   RUBY_VERSION = File
     .read("#{File.dirname(__FILE__)}/../../.ruby-version")

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: hephaestus
 version: !ruby/object:Gem::Version
-  version: 0.8.12.2
+  version: 0.8.13
 platform: ruby
 authors:
 - Garen Torikian
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2024-12-17 00:00:00.000000000 Z
+date: 2024-12-18 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bootsnap