How would be the authentication/authorization work with this approach?

- - Ivan

On Wed, Sep 13, 2017 at 9:05 PM,  <[email protected]> wrote:
>
> First attempt to create a design. It's an open discussion, everyone who
> wants to chime in, please do.
>
> The engine: will be deployed as a separate gem. My name suggestion
> the-detective (Sinatra plays a cop).
>
> It will wrap the invocation of rubocop with defaults and parameters needed
> to support our use case:
> 1. Support for erb
> 2. Support for completely customized set of cops.
> 3. Parametrized list of folders containing cops to be added to the list.
>
> In addition it will add tooling to expose a rack endpoint for rubocop
> invocation:
> 1. List of all available cops (kind of metadata)
> 2. A POST method that receives a source file, list of cops, and output
> format that will return the result of rubocop's analysis.
> 3. Will be mountable to any Rails application
> 4. Will have an option to run as a standalone process (probably using
> passenger with sort-lived process retention settings, since its one process
> per request nature)
>
> Usage for foreman needs:
>
> Use case 1 (community templates CI):
> 1. Reference the detective gem from templates plugin.
> 2. Deploy foreman-core with templates plugin enabled.
> 3. Add rake task that will invoke rubocop on specified folder using
> detective's invocation wrapper.
>
> Use case 2 (Validate single template from templates UI)
> 1. Reference detective gem from templates plugin.
> 2. Add cops declaration ability to plugins in foreman core
> 3. Templates plugin is responsible for adding/maintaining detective's
> endpoint.
> 4. Foreman core exposes an option to add actions to template editing screen.
> 5. Templates plugin uses extension point from 4 to add its own action that
> will invoke detective's endpoint and modify template editor to show the
> result as linting (it's possible with ace and monaco).
>
> Use case 3 (upgrade scenario):
> As a first step, we can try and report broken templates after the upgrade.
> It will be pretty similar to community templates CI use case, only the
> templates code will be exported from user's database.
>
>
> I want to start working on the engine gem as soon as possible, so I would
> really appreciate any inputs on the process before I have started with this
> implementation.
>
> Shim.
>
>
>
> On Wednesday, August 30, 2017 at 11:48:09 AM UTC+3, [email protected] wrote:
>>
>>
>> After a great talk on community demo, here is a follow up with the points
>> that were raised during the discussion:
>>
>> Use cases:
>>
>> Run all cops as part of community templates CI against the whole
>> repository
>> Run all cops against a single template invoked by the user from template
>> editing screen (foreman core)
>> Upgrade scenario: Preferably run cops for the next foreman version before
>> the actual upgrade to make sure the templates will remain valid.
>>
>>
>> Features:
>>
>> List of rues should be pluggable [Shim]: It looks like it is a must-have
>> for the engine.
>> Deployment options
>>
>> Engine as a separate gem, cops in a relevant repository - core cops in
>> core, plugin cops in plugins.
>> Engine with all cops in a single gem, versioned per foreman version.
>> Engine as part of templates plugin, cops as part of relevant plugins.
>> Separate gems for everything: foreman-cops-engine, foreman-cops-core,
>> foreman-cops-plugin1, foreman-cops-plugin2 e.t.c. Engine is versioned per
>> foreman release version (for the sake of rubocop version), cops are
>> versioned per plugin version.
>>
>> General comments:
>>
>> Cops writing should be enforced on PR's that are changing the way to write
>> templates [mhulan]
>> Cops are dependent on core/plugin version [gwmngilfen]
>>
>>
>>
>>
>> On Monday, August 14, 2017 at 2:29:02 PM UTC+3, [email protected] wrote:
>>>
>>> TL;DR: I have developed a way to scan any template and see if there are
>>> suspicious/incorrect code patterns in them, so the templates will remain
>>> valid even after foreman code changes.
>>>
>>> Recently I have started to think about user created templates and foreman
>>> upgrades.
>>>
>>> When user upgrades foreman, hist default templates get upgraded by the
>>> installer/migrations, but templates created by the user (both cloned and
>>> from scratch) are not touched.
>>> This could lead to invalid templates and broken provisioning
>>> functionality for the user.
>>> Good example for this would be the change from calling to <%= foreman_url
>>> %> to <%= foreman_url('built') %>
>>>
>>> I was looking for a way to inspect any template, in order to identify
>>> problematic code as soon as the system is upgraded.
>>>
>>> I came down to a solution based on rubocop - it's already analyzing
>>> source files for patterns.
>>> I have created a POC that analyzes a template written to a file, and
>>> presents the resulting errors as regular rubocop (clang style).
>>> All source codes are available as gist:
>>> https://gist.github.com/ShimShtein/341b746f15826261053e97c2f435ff1a
>>>
>>> Small explanation for the gist:
>>>
>>> Entry point: inspect_template.rb
>>> Usage:
>>> Put everything from the gist to a single folder and execute:
>>>>
>>>> inspect_template /path/to/template_source.erb
>>>
>>> This script aggregates all the parts that are needed to create the
>>> clang-like output.
>>>
>>> The process:
>>>
>>> Strip all non-ruby text from the template. This is done by erb_strip.rb.
>>> It turns everything that is not a ruby code into spaces, so the ruby code
>>> remains in the same places as it was in the original file.
>>> Run rubocop with custom rules and erb monkey patch and produce a json
>>> report
>>>
>>> foreman_callback_cop.rb custom rule file. The most interesting line is
>>> "def_node_matcher :foreman_url_call?, '(send nil :foreman_url)'". Here you
>>> define which pattern to look for in the AST, in our case we are looking for
>>> calls (send) for foreman_url method without parameters.
>>> foreman_erb_monkey_patch.rb file: Patches rubocop engine to treat *.erb
>>> files as source files and not skip them.
>>>
>>> Process the resulting json to convert it to clang style highlighting.
>>>
>>> Possible usages:
>>>
>>> Scanning all template after foreman upgrade to see that they are still
>>> valid.
>>> Linting a template while while editing.
>>> Using rubocop's autocorrect feature to automatically fix offences found
>>> by this process.
>>>
>>> Long shot: we can create custom rules to inspect code for our plugins
>>> too, especially if we start creating custom rules in rubocop.
>>>
>>> I am interested in comments, opinions and usages to see how to proceed
>>> from here.
>>>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to