When its property seems to be broken

Description :
The following when condition doesn't seem to work
When its property is true
When its property is int
To Reproduce

<Either a sample terraform code, or your terraform plan file if it doesn't have any confidential information>

resource "aws_security_group" "ecs_task" {
  name        = "ecs-tasks"
  description = "Allow ECS Fargate tasks to communicate with each other"
  vpc_id      = var.vpc_id

  timeouts {
    create = "5m"
    delete = "5m"
  }
}

resource "aws_security_group_rule" "ecs_task_ingress_self" {
  type              = "ingress"
  description       = "Allow ECS task to communicate with itself (ingress)"
  security_group_id = aws_security_group.ecs_task.id
  protocol          = "tcp"
  from_port         = 0
  to_port           = 65535
  self              = true
}

resource "aws_security_group_rule" "ecs_task_egress_self" {
  type              = "egress"
  description       = "Allow ECS task to communicate with itself (egress)"
  security_group_id = aws_security_group.ecs_task.id
  protocol          = "tcp"
  from_port         = 0
  to_port           = 65535
  self              = true
}

resource "aws_security_group_rule" "ecs_task_egress_to_internet_443" {
  type              = "egress"
  description       = "Allow ECS task to communicate with Internet on 443"
  security_group_id = aws_security_group.ecs_task.id
  protocol          = "tcp"
  from_port         = 443
  to_port           = 443
  #tfsec:ignore:AWS007
  cidr_blocks = ["<IP_ADDRESS>/0"]
}

resource "aws_security_group_rule" "ecs_task_egress_to_mssql" {
  type              = "egress"
  description       = "Allow ECS task to communicate with MSSQL"
  security_group_id = aws_security_group.ecs_task.id
  protocol          = "tcp"
  from_port         = 1433
  to_port           = 1433
  cidr_blocks       = ["<IP_ADDRESS>/16"]
}

-f features
docker
See below

Feature: Security group(s) attached to ECS task must restrict inbound and outbound traffic  # /opt/app/test/ecs-sg.feature

    Scenario Outline: ECS security group allows communication with itself
        Given I have aws_security_group_rule defined
        When its security_group_id reference is "aws_security_group.ecs_task"
        And its self is true
        Then its protocol must be tcp
        And its from_port must be 0
        And its to_port must be 65535
        And its type must be <type>

    Examples:
        | type    |
        💡 SKIPPING: Can not find true self in aws_security_group_rule.ecs_task_egress_self, aws_security_group_rule.ecs_task_egress_to_internet_443, aws_security_group_rule.ecs_task_egress_to_mssql, aws_security_group_rule.ecs_task_ingress_self.
        | ingress |
        💡 SKIPPING: Can not find true self in aws_security_group_rule.ecs_task_egress_self, aws_security_group_rule.ecs_task_egress_to_internet_443, aws_security_group_rule.ecs_task_egress_to_mssql, aws_security_group_rule.ecs_task_ingress_self.
        | egress  |

    Scenario: ECS task security group allows egress to Internet on port 443
        Given I have aws_security_group_rule defined
        When its security_group_id reference is "aws_security_group.ecs_task"
        💡 SKIPPING: Can not find 443 from_port in aws_security_group_rule.ecs_task_egress_self, aws_security_group_rule.ecs_task_egress_to_internet_443, aws_security_group_rule.ecs_task_egress_to_mssql, aws_security_group_rule.ecs_task_ingress_self.
        And its from_port is 443
        Then its protocol must be tcp
        And its to_port must be 443
        And it must contain cidr_block
        And its value must contain <IP_ADDRESS>/0

<Your feature/scenario/steps>

Feature: Security group(s) attached to ECS task must restrict inbound and outbound traffic

  Scenario Outline: ECS security group allows communication with itself
    Given I have aws_security_group_rule defined
    When its security_group_id reference is "aws_security_group.ecs_task"
    And its self is true
    Then its protocol must be tcp
    And its from_port must be 0
    And its to_port must be 65535
    And its type must be <type>

    Examples:
      | type    |
      | ingress |
      | egress  |

  Scenario: ECS task security group allows egress to Internet on port 443
    Given I have aws_security_group_rule defined
    When its security_group_id reference is "aws_security_group.ecs_task"
    And its from_port is 443
    Then its protocol must be tcp
    And its to_port must be 443
    And it must contain cidr_block
    And its value must contain <IP_ADDRESS>/0

Expected behavior :
All above tests passed
Tested versions :

1.1.15
0.12.24

Additional context
Add any other context about the problem here.

Thanks for the issue 🎉 . Fixed the problem.
It looks like we also need to extend the Security Group step (e.g. Then it must have tcp protocol and port 443 for <IP_ADDRESS>/0') to Security Group Rules. Since your Scenario could be much shorter and effective.

Just enabled Security Group related step to process Security Group Rules also.
    Scenario: Ensure ECS Task SGR has tcp/443 defined for public network
        Given I have aws_security_group_rule defined
        When its security_group_id reference is "aws_security_group.ecs_task"
        And its type is egress
        And its from_port is 443
        Then it must have tcp protocol and port 443 for <IP_ADDRESS>/0'

even, you can check your all egress traffic for that specific ecs_task like ;
    Scenario: Ensure ECS Task SGR has only tcp/443 for public network
        Given I have aws_security_group_rule defined
        When its security_group_id reference is "aws_security_group.ecs_task"
        And its type is egress
        Then it must have tcp protocol and port 443 for <IP_ADDRESS>/0'

will release this today.


Turning helper methods of annotation_categories_helper into class methods in the AnnotationCategory model

Motivation and Context

Some helper methods inside app/helpers/annotation_categories_helper really belonged as class ("static") methods inside the AnnotationCategory model. The purpose of this pull request relates to a small refactoring in the codebase required to move these helper methods to the AnnotationCategory model.
Your Changes

Description: Refactored the methods annotation_categories_to_yml and upload_annotations_from_yaml from the helper module app/helpers/annotations_categories_helper to move them into the AnnotationCategory. For upload_annotations_from_yaml, its implementation is using the current_role method from the app/lib/session_handler module. This method is directly accessible from within controllers and helpers, but not in models. Thus, I added a current_role parameter to the upload_annotations_from_yaml class method, so its invocations (all of which happen in a model, where the current_role is directly accessible) pass a valid current_role.
Type of change (select all that apply):

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] Refactoring (internal change to codebase, without changing functionality)
[ ] Test update (change that modifies or updates tests only)
[ ] Other (please specify):

Testing

I ensured all rspec tests run successfully. In particular one test was failing initially (spec/controllers/annotation_categories_controller_spec.rb), so I called rspec for just that test until I solved the issue. Then I ran the entire test suite again to ensure everything is fine. Additionally, I checked that the UI is still functioning as expected with regard to the components related to my change.
Questions and Comments (if applicable)

Checklist

[x] I have performed a self-review of my own code.
[x] I have verified that the pre-commit.ci checks have passed.
[x] I have verified that the CI tests have passed.
[ ] I have reviewed the test coverage changes reported on Coveralls.
[ ] I have added tests for my changes.
[x] I have updated the Changelog.md file.
[ ] I have made changes to the documentation and linked to that pull request below.

Pull request to make documentation changes (if applicable)

Thank you professor, I will get started with these right away. I had a small question:
Right before I made the pull request last week, I updated my local git repository with upstream (by first pulling from the upstream master to my local master, and then merging my local master branch into my local fix-static-methods branch). Then I ran the rspec test suite and there were no failures (so afterwards I confidently made the pull request).
However, I see here in this pull request that a check failed (an image of this is seen below). So I went to my local repository and updated with upstream again to rerun rspec, and after all tests ran I got the following output (which I had not gotten again previously): "Pending: (Failures listed here are expected and do not affect your suite's status)". I also included an image with the exact output.
Is this a problem on my side, or is it anticipated? I am thinking something changed in the upstream since I last made the pull request maybe.

Have a great day!
Mimis

@mimischly7 oh don't worry about that, it's a problem with how our tests are currently configured on GitHub Actions. I noticed it while reviewing your and Bruce's PRs, and I've actually just made a fix (#6750)


Specifying existing instances on the fly

Docs describe it is possible to define an injection by specifingy a pre-existing instance instead of the string class name:
$injector->define('MyClass', [':dependency' => $dependencyInstance]);

However, make only allows to override definition by using a different class name and not a given instance:
$myObj = $injector->make('MyClass', ['dependency' => 'SomeImplementation']);

If I try to pass it an instance it throws:
Warning: strtolower() expects parameter 1 to be string, object given in /xxxxx/vendor/rdlowrey/auryn/lib/Provider.php on line 752

Is this allowed or I'm just doing it wrong?

If you share a pre-existing instance, then anywhere you typehint for it the shared one will be used. Is that what you're after?
I tend to share things like my DB / ORM classes in the bootstrap. Be aware that when you share them though, you have to create them. So only do this with core classes if they have a heavy footprint. Again factories can be helpful here or even delegate (but I haven't used that yet).

On 28 Feb 2015, at 10:08, Raúl Ferràs<EMAIL_ADDRESS>wrote:
Docs describe it is possible to define an injection by specifingy a pre-existing instance instead of the string class name:
$injector->define('MyClass', [':dependency' => $dependencyInstance]);
However, make only allows to override definition by using a different class name and not a given instance:
$myObj = $injector->make('MyClass', ['dependency' => 'SomeImplementation']);
If I try to pass it an instance it throws:
Warning: strtolower() expects parameter 1 to be string, object given in /xxxxx/vendor/rdlowrey/auryn/lib/Provider.php on line 752
Is this allowed or I'm just doing it wrong?
—
Reply to this email directly or view it on GitHub.

No, I'm trying to create an object that needs a specific EventDispatcher:
$eventDispatcher = new EventDispatcher();
// configure the dispatcher by hooking to events.
$kernel = $injector->make('HttpKernel:,

array('dispatcher'=>$eventDispatcher));
This resides in a closed scope an no other place in application will need
this instance of $kernel. Other possible HttpKernel instances may need
its own unique dependency instances so this is not a singleton-like
instance.
El 28/02/2015 11:12, "James Mallison"<EMAIL_ADDRESS>escribió:

If you share a pre-existing instance, then anywhere you typehint for it
the shared one will be used. Is that what you're after?
I tend to share things like my DB / ORM classes in the bootstrap. Be aware
that when you share them though, you have to create them. So only do this
with core classes if they have a heavy footprint. Again factories can be
helpful here or even delegate (but I haven't used that yet).

On 28 Feb 2015, at 10:08, Raúl Ferràs<EMAIL_ADDRESS>wrote:
Docs describe it is possible to define an injection by specifingy a
pre-existing instance instead of the string class name:
$injector->define('MyClass', [':dependency' => $dependencyInstance]);
However, make only allows to override definition by using a different
class name and not a given instance:
$myObj = $injector->make('MyClass', ['dependency' =>
'SomeImplementation']);
If I try to pass it an instance it throws:
Warning: strtolower() expects parameter 1 to be string, object given in
/xxxxx/vendor/rdlowrey/auryn/lib/Provider.php on line 752
Is this allowed or I'm just doing it wrong?
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/rdlowrey/Auryn/issues/78#issuecomment-76520126.

Oh, re-reading your response I see you are refering to sharing my
EventDispatcher.
I don't see why I would want to share it, but it will solve the
situation.Anyway I don't think there's need to share the dispatcher
everywhere.
El 28/02/2015 11:22, "Raúl Ferràs"<EMAIL_ADDRESS>escribió:

No, I'm trying to create an object that needs a specific EventDispatcher:
$eventDispatcher = new EventDispatcher();
// configure the dispatcher by hooking to events.
$kernel = $injector->make('HttpKernel:,

array('dispatcher'=>$eventDispatcher));
This resides in a closed scope an no other place in application will need
this instance of $kernel. Other possible HttpKernel instances may need
its own unique dependency instances so this is not a singleton-like
instance.
El 28/02/2015 11:12, "James Mallison"<EMAIL_ADDRESS>escribió:

If you share a pre-existing instance, then anywhere you typehint for it
the shared one will be used. Is that what you're after?
I tend to share things like my DB / ORM classes in the bootstrap. Be
aware that when you share them though, you have to create them. So only do
this with core classes if they have a heavy footprint. Again factories can
be helpful here or even delegate (but I haven't used that yet).

On 28 Feb 2015, at 10:08, Raúl Ferràs<EMAIL_ADDRESS>wrote:
Docs describe it is possible to define an injection by specifingy a
pre-existing instance instead of the string class name:
$injector->define('MyClass', [':dependency' => $dependencyInstance]);
However, make only allows to override definition by using a different
class name and not a given instance:
$myObj = $injector->make('MyClass', ['dependency' =>
'SomeImplementation']);
If I try to pass it an instance it throws:
Warning: strtolower() expects parameter 1 to be string, object given in
/xxxxx/vendor/rdlowrey/auryn/lib/Provider.php on line 752
Is this allowed or I'm just doing it wrong?
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/rdlowrey/Auryn/issues/78#issuecomment-76520126.

If you look at "Using Existing Instances in Injection Definitions" in the readme, there are two steps you do: define the dependency as your instance (don't forget the semicolon) and then make it:
$injector->define('MyClass', [':dependency' => $dependencyInstance]);
$myObj = $injector->make('MyClass');
':dependency' is the name  of the dependency parameter I believe.

On 28 Feb 2015, at 10:25, Raúl Ferràs<EMAIL_ADDRESS>wrote:
Oh, re-reading your response I see you are refering to sharing my
EventDispatcher.
I don't see why I would want to share it, but it will solve the
situation.Anyway I don't think there's need to share the dispatcher
everywhere.
El 28/02/2015 11:22, "Raúl Ferràs"<EMAIL_ADDRESS>escribió:

No, I'm trying to create an object that needs a specific EventDispatcher:
$eventDispatcher = new EventDispatcher();
// configure the dispatcher by hooking to events.
$kernel = $injector->make('HttpKernel:,
array('dispatcher'=>$eventDispatcher));
This resides in a closed scope an no other place in application will need
this instance of $kernel. Other possible HttpKernel instances may need
its own unique dependency instances so this is not a singleton-like
instance.
El 28/02/2015 11:12, "James Mallison"<EMAIL_ADDRESS>escribió:

If you share a pre-existing instance, then anywhere you typehint for it
the shared one will be used. Is that what you're after?
I tend to share things like my DB / ORM classes in the bootstrap. Be
aware that when you share them though, you have to create them. So only do
this with core classes if they have a heavy footprint. Again factories can
be helpful here or even delegate (but I haven't used that yet).

On 28 Feb 2015, at 10:08, Raúl Ferràs<EMAIL_ADDRESS>wrote:
Docs describe it is possible to define an injection by specifingy a
pre-existing instance instead of the string class name:
$injector->define('MyClass', [':dependency' => $dependencyInstance]);
However, make only allows to override definition by using a different
class name and not a given instance:
$myObj = $injector->make('MyClass', ['dependency' =>
'SomeImplementation']);
If I try to pass it an instance it throws:
Warning: strtolower() expects parameter 1 to be string, object given in
/xxxxx/vendor/rdlowrey/auryn/lib/Provider.php on line 752
Is this allowed or I'm just doing it wrong?
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/rdlowrey/Auryn/issues/78#issuecomment-76520126.

—
Reply to this email directly or view it on GitHub.

But what if later in another place I want to instantiate a different
HttpKernel? Wouldn't it try to use that definition again?
I forgot to say I already have a definition earlier in code for HttpKernel
to resolve the interfaces it is type hinting:
$injector->define('HttpKernel',

array('EventDispatcherInterface'=>'EventDispatcher'));
So by default auryn provides a new instance of EventDispatcher.
If I redefine it as you say, I'm overwriting this earlier definition and
subsequent instantiations will try to use the later definition. Isn't?
El 28/02/2015 11:46, "James Mallison"<EMAIL_ADDRESS>escribió:

If you look at "Using Existing Instances in Injection Definitions" in the
readme, there are two steps you do: define the dependency as your instance
(don't forget the semicolon) and then make it:
$injector->define('MyClass', [':dependency' => $dependencyInstance]);
$myObj = $injector->make('MyClass');
':dependency' is the name of the dependency parameter I believe.

On 28 Feb 2015, at 10:25, Raúl Ferràs<EMAIL_ADDRESS>wrote:
Oh, re-reading your response I see you are refering to sharing my
EventDispatcher.
I don't see why I would want to share it, but it will solve the
situation.Anyway I don't think there's need to share the dispatcher
everywhere.
El 28/02/2015 11:22, "Raúl Ferràs"<EMAIL_ADDRESS>escribió:

No, I'm trying to create an object that needs a specific
EventDispatcher:
$eventDispatcher = new EventDispatcher();
// configure the dispatcher by hooking to events.
$kernel = $injector->make('HttpKernel:,
array('dispatcher'=>$eventDispatcher));
This resides in a closed scope an no other place in application will
need
this instance of $kernel. Other possible HttpKernel instances may
need
its own unique dependency instances so this is not a singleton-like
instance.
El 28/02/2015 11:12, "James Mallison"<EMAIL_ADDRESS>escribió:

If you share a pre-existing instance, then anywhere you typehint
for it
the shared one will be used. Is that what you're after?
I tend to share things like my DB / ORM classes in the bootstrap. Be
aware that when you share them though, you have to create them. So
only do
this with core classes if they have a heavy footprint. Again
factories can
be helpful here or even delegate (but I haven't used that yet).

On 28 Feb 2015, at 10:08, Raúl Ferràs<EMAIL_ADDRESS>wrote:
Docs describe it is possible to define an injection by specifingy a
pre-existing instance instead of the string class name:
$injector->define('MyClass', [':dependency' =>
$dependencyInstance]);
However, make only allows to override definition by using a
different
class name and not a given instance:
$myObj = $injector->make('MyClass', ['dependency' =>
'SomeImplementation']);
If I try to pass it an instance it throws:
Warning: strtolower() expects parameter 1 to be string, object
given in
/xxxxx/vendor/rdlowrey/auryn/lib/Provider.php on line 752
Is this allowed or I'm just doing it wrong?
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/rdlowrey/Auryn/issues/78#issuecomment-76520126.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/rdlowrey/Auryn/issues/78#issuecomment-76521067.

So I had a Configuration object that I wanted a different instance of in different places. Logically, I had to provide a configuration for this.
So, I created a config file that I read from. In it, I state the object as the key and the config parameters as values.
In my code, I loop through the arrays, and define the object and associated values so that each object will have its own instance of the Configuration with its own values.
In fact, I have aliases, definitions and more in a config file so I can add/remove them at will and the application picks up the change and continues.
Just an example of what I've done - perhaps that might help you? I think Auryn provides a clear or reset or similar method or you can override an object with another. Best place for this would be a factory because they can have access to the injector if needed.

On 28 Feb 2015, at 10:57, Raúl Ferràs<EMAIL_ADDRESS>wrote:
But what if later in another place I want to instantiate a different
HttpKernel? Wouldn't it try to use that definition again?
I forgot to say I already have a definition earlier in code for HttpKernel
to resolve the interfaces it is type hinting:
$injector->define('HttpKernel',
array('EventDispatcherInterface'=>'EventDispatcher'));
So by default auryn provides a new instance of EventDispatcher.
If I redefine it as you say, I'm overwriting this earlier definition and
subsequent instantiations will try to use the later definition. Isn't?
El 28/02/2015 11:46, "James Mallison"<EMAIL_ADDRESS>escribió:

If you look at "Using Existing Instances in Injection Definitions" in the
readme, there are two steps you do: define the dependency as your instance
(don't forget the semicolon) and then make it:
$injector->define('MyClass', [':dependency' => $dependencyInstance]);
$myObj = $injector->make('MyClass');
':dependency' is the name of the dependency parameter I believe.

On 28 Feb 2015, at 10:25, Raúl Ferràs<EMAIL_ADDRESS>wrote:
Oh, re-reading your response I see you are refering to sharing my
EventDispatcher.
I don't see why I would want to share it, but it will solve the
situation.Anyway I don't think there's need to share the dispatcher
everywhere.
El 28/02/2015 11:22, "Raúl Ferràs"<EMAIL_ADDRESS>escribió:

No, I'm trying to create an object that needs a specific
EventDispatcher:
$eventDispatcher = new EventDispatcher();
// configure the dispatcher by hooking to events.
$kernel = $injector->make('HttpKernel:,
array('dispatcher'=>$eventDispatcher));
This resides in a closed scope an no other place in application will
need
this instance of $kernel. Other possible HttpKernel instances may
need
its own unique dependency instances so this is not a singleton-like
instance.
El 28/02/2015 11:12, "James Mallison"<EMAIL_ADDRESS>escribió:

If you share a pre-existing instance, then anywhere you typehint
for it
the shared one will be used. Is that what you're after?
I tend to share things like my DB / ORM classes in the bootstrap. Be
aware that when you share them though, you have to create them. So
only do
this with core classes if they have a heavy footprint. Again
factories can
be helpful here or even delegate (but I haven't used that yet).

On 28 Feb 2015, at 10:08, Raúl Ferràs<EMAIL_ADDRESS>wrote:
Docs describe it is possible to define an injection by specifingy a
pre-existing instance instead of the string class name:
$injector->define('MyClass', [':dependency' =>
$dependencyInstance]);
However, make only allows to override definition by using a
different
class name and not a given instance:
$myObj = $injector->make('MyClass', ['dependency' =>
'SomeImplementation']);
If I try to pass it an instance it throws:
Warning: strtolower() expects parameter 1 to be string, object
given in
/xxxxx/vendor/rdlowrey/auryn/lib/Provider.php on line 752
Is this allowed or I'm just doing it wrong?
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/rdlowrey/Auryn/issues/78#issuecomment-76520126.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/rdlowrey/Auryn/issues/78#issuecomment-76521067.

—
Reply to this email directly or view it on GitHub.

What if I don't know the value of those parameters in advance?
Say I got a view factory:
class ViewFactory{
    public function __construct($viewName,$paths){
        $this->viewName = $viewName;
        $this->paths = $paths;
    }

   public function make()
   {
         $view = new View($this->viewName,$this->paths);
         return $view;
   }

}
If in my application bootstrap I do a definition like this:
$injection->share('ViewFactory');

Later in my controllers I will call $injection->make('ViewFactory') to create a new view, each one obviously with different parameters. You're telling me I need to create different definitions to create different views... Why don't simply be pass those dynamic values as parameters to make method? Isn't this the purpose of the injector? Why limit only in definition time?

As soon as you hit your controller layer, you shouldn't need to use the injector. Why does the make method not use viewName and paths as parameters? Your current object API States that to make multiple views, you're also going to have to make multiple ViewFactories. Doesn't seem right to me...

On 2 Mar 2015, at 09:02, Raúl Ferràs<EMAIL_ADDRESS>wrote:
What if I don't know the value of those parameters in advance?
Say I got a view factory:
class ViewFactory{
public function __construct($viewName,$paths){
$this->viewName = $viewName;
$this->paths = $paths;
}
public function make()
{
$view = new View($this->viewName,$this->paths);
return $view;
}
}
If in my application bootstrap I do a definition like this:
$injection->share('ViewFactory');
Later in my controllers I will call $injection->make('ViewFactory') to create a new view, each one obviously with different parameters. You're telling me I need to create different definitions to create different views... Why don't simply be pass those dynamic values as parameters to make method? Isn't this the purpose of the injector? Why limit only in definition time?
—
Reply to this email directly or view it on GitHub.

I agree with that, I'm just trying to show an example where I would need make use of that make/execute calls overwriting with instances some of their parameters, but it seems I can't hit gold...
Maybe I'm trying to use this injector in a wrong way.

Sorry I'm late to the party on this but it looks like a simple syntax error:
$myObj = $injector->make('MyClass', ['dependency' => 'SomeImplementation']);

^ this results in the error because you haven't prefixed the raw parameter indicator (:) to the dependency param name. Everything should work as expected (from the original issue report) if you change the above code to this:
$myObj = $injector->make('MyClass', [':dependency' => 'SomeImplementation']);

I think the being able to pass in custom params by type name as well as by parameter name, as it makes programs be more maintainable, examplé:
function createFoo(Bar $iAmProgrammerWhoGivesParametersWeirdNames) {
    return new Foo($iAmProgrammerWhoGivesParametersWeirdNames);
}

$injector->delegate('Foo', 'createFoo');

500 lines later or in a totally different file, it's easier/saner to do:
$customBar = new Bar(1234);
$injector->make('Foo', [Bar::class => $customBar]);

As that gets inspection and code refactoring support, whereas the param names don't.
Rather than:
$customBar = new Bar(1234);
$injector->make('Foo', [':iAmProgrammerWhoGivesParametersWeirdNames' => $customBar]);

Trivial PR that I forgot to do in a new branch so am waiting till the other PR gets merged: https://github.com/Danack/Auryn/commit/a3590f2f7541618f281aaa6b9d544dfa14f22a07

The counter argument to allowing types to be allowed in as the custom args is that it's less confusing overall. For various reasons (but particularly this one, the instances specified as custom instances to make don't get passed to the dependencies that are required for the class being instantiated. e.g.
class Foo {
    function __construct(Bar $bar) {
    }
}

class Bar{
    function __construct(Baz $baz) {
    }
}

$bazInstance = new Baz();

$injector->make('Foo', ['Baz' => $bazInstance]); //I would expect the instance would be used wherever a Baz object is required.

The $bazInstance does not get passed through to the Bar constructor. This is more surprising when the custom arg is specified by type name. When it's specified by just the parameter name, it's slightly more intuitive to me that it's just going to be used directly for the creation of the thing being requested, and not passed through to other objects.
I'm really on the fence about this; having it done by parameter name makes the parameter name be part of the signature of the function that is called to create the object which I strongly dislike, and having it be done by type name is more confusing.

You know, we could just remove the args from make and execute. They aren't powerful enough to cater to all needs, they're pretty confusing (particularly with regard to shared/singleton objects), and cloning the injector gives everything that you would need.
$injector = clone $originalInjector;
$injector->alias('Dispatcher', get_class($eventDispatcher));
$injector->share($eventDispatcher);
$kernel = $injector->make('HttpKernel');

All the having to think about it goes away.....

Make / execute args, unless there's an alternative for those on-the-fly args, are critical for what I use the lib for (automatic controller instantiation, injection and 'slugs' from request args).

I'm in a similar position to @J7mbo above, being able to specify args on-the-fly is a big part of my use case for Auryn (and IMO one of its best features).

and IMO one of its best features.

It's one of it's most useful features.....I don't think it can be the best as it has the quite surprising and almost certainly undesired behaviour I noted above, of sometimes using the extra args, and other times just ignoring them.
I can understand why you wouldn't want it removed - but I don't think it's that difficult to reimplement in a more reasonaboutable way.
function makeOnTheFly(Injector $originalInjector, $type, $oneOffArgs) {
    $injector = clone $originalInjector;

    foreach ($oneOffArgs as $key => $value) {
        if(substr($key, 0, 1) === ':') {
            $paramName = substr($key, 1);
            $injector->defineParam($paramName, $value);
        }
        else if (is_object($value)) {
            $injector->alias($key, get_class($value));
            $injector->share($key, $value);
        }
        else {
            $injector->alias($key, $value);
         }
    }

    return $injector->make($type);
}

The only thing that this wouldn't allow is the passing of parameters by order....

I'm a bit confused, so can I clarify something:
Are you saying that overriding parameters should (or could, rather) be done by type name in addition to parameter name, but that adding this feature would make the ability to pass in overrides confusing as they wouldn't be used throughout the dependency-resolution (as far as then creating child objects goes)?

This is already possible, you just forgot the : for that says it's a raw value instead of a class name.

I don't think the example covers what is being discussed here. What we want is to specify args by its class name and not args name (what your example is about). For examples:
"stdClass" => $stdClass

The initial issue has been:

However, make only allows to override definition by using a different class name and not a given instance:

A given instance is possible.
Please open another issue instead of mixing two issues.

All right, here it is: https://github.com/rdlowrey/auryn/issues/154


CB-12622: (android) Adapt Appium tests for Android 6 and 7

Platforms affected
Android
What does this PR do?
Makes Appium tests honor the selenium quirk which leads to stack overflow on Android 6 and 7.
Also, adds a permission dialog buster for Appium tests.
What testing has been done on this change?
Ran tests on Sauce Labs for Android 6 and 7 emulators.
Checklist

[x] Reported an issue in the JIRA database
[x] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
[ ] Added automated test coverage as appropriate for this change.

Cordova CI Build has one or more failures.
Commit     - Link
Dashboard - Link
236 tests run, 17 skipped, 5 failed.

Cordova CI Build has completed successfully.
Commit     - Link
Dashboard - Link
236 tests run, 17 skipped, 0 failed.


Accept File Paths Without Specifying Put

Instead of
gtrash put path/to/file

It would be nice if
gtrash path/to/file

also worked. Many users, including myself, creating shell functions for trash like
trash() {
    gtrash put "$@"
}
# Or
rm() {
    gtrash put "$@"
}

But if we do this then
trash --help

does not work as expected. This may also work better when interacting with other programs and scripts.

Sorry this is intentional, i chose the sub commands design because I want it to be featureful and single binary.
If you do not want to type sub commands such as 'gtrash put', you can set an alias or create a wrapper script to the following.
https://github.com/umlx5h/gtrash?tab=readme-ov-file#can-i-run-trash-put-in-one-command-without-using-alias
$ sudo vim /usr/local/bin/trash
#!/bin/sh

# Specify gtrash binary path
exec /usr/local/bin/gtrash put "$@"

$ sudo chmod a+x /usr/local/bin/trash

$ trash somefile

Since trash-cli is normally used 99% of the time for deleting files, it seems reasonable to use aliases or the wrapper only there. Operations such as restore do not require aliases for me.
I'm not interested in implementing 'put syntax sugar' because usually aliases and the wrapper are enough and it will introduce side effects such as the following.

can not delete a file with same name as a subcommand, e.g. put, restore
incompatible with shell auto-completion
it may be dangerous

But if we do this then trash --help does not work as expected.

You can set an alias instead of function, then --help will work
zsh
$ alias tt="gtrash put"

$ tt --help
Description:
  A substitute for 'rm', moving files to the trash.


Make "Click to load panorama" a  element for better accessibility

Right now the "Click to load panorama" button is a
 tag:

Click to

    Load

    Panorama

Making this a <button> tag will make it keyboard focusable which is critical for accessibility.
Proposed markup/changes:

  <button>Click to

    Load

    Panorama
  </button>

Completing this change is a huge win for keyboard users and will allow people to use and explore Pannellum images.
At a quick glance, looks like you could change pannellum.js line 2098. You'll have to style the button and move focus back to .pnlm-container.

🙏  Thanks for the awesome library! 👍

I fixed this in 9df0b8bd98557c6ff197c5339289e67585c285e9. This is something I've known about for a while but needed someone asking about it prioritize fixing it.

This is fantastic, Matt. Thank you! I cloned this project and built the CSS & JS from source, then included those files in our project. Works great!
If you get some time to push out a release, I'm sure a lot of folks would be grateful. Thanks again.

Based on my current schedule, I don't think I'll have time to get a release out in the next couple months, but there should be one before the end of the year.


Feed style

Styling for the reviews page (feed.html)

Can't resolve all conflicts right now because master branch has missing "div"

What do you mean cannot resolve all conflicts?

What do you mean cannot resolve all conflicts?

@jiangyue12392 means conflicts with master branch that can't be resolved right now in feed.html page


Fingerbot: Device is not registered

All-time the same message for fingerbot bluetooth on rasp4. HA OS.
Testing whit many forks.
Device is not registered in Tuya cloud

@BerurierNoir See my comment on the #119 thread, maybe it helps?
I can at least now add the device, but can't controls, shows as unavailable.

It is indeed a small victory. But if it remains unusable, it's still complicated.
I tried many forks and different configurations, but nothing worked.
Were there no custom firmwares available for the Fingerbot? I couldn't find any.

same problem here...

@Moe555 check my comment in the other thread, I've been using the integration all August and September and it's been pretty stable for me, in combination with ESPHome Bluetooth Proxies. I was able to add my devices, I had to make sure they are in good range of the proxies and give time to HA and the Tuya BLE Integration to find the device on its own until they show up as discovered devices in the interface, then add them. Prior adding them to my Tuya dev account via Smart Life, as well

Thanks for your reply.
I saw your reply there as well, I will answer to that one.


Enhanced exception UX

Replaced a lot of raw RuntimeExceptions with more specific throwables
Split up PermissionException into InsufficientPermissionException and HierarchyException for userfriendly multi-catch

I would only merge this for the next minor/major version update due to it very likely breaking user-code

This does not affect user code in any way as all new exceptions are children of the previous

Oh right, i somehow thought InsufficientPermEx was a rename of normal PermEx :)

That last commit: the most random changes :)


unable to open miniedit.py

Traceback (most recent call last):
File "./miniedit.py", line 63, in
from mininet.log import info, debug, warn, setLogLevel
ImportError: No module named mininet.log

have you correctly installed mininet?


Record trailing line dbg instructions

There is nothing in the spir-v spec that says the last
instructions in a module cannot be OpLine or OpNoLine.
However, the code that parses the module will simply drop
these instructions.
We add code that will preserve these instructions.
Strip-debug-info is updated to remove these instructions.
Fixes https://crbug.com/1000689.

This should get rebased onto https://github.com/KhronosGroup/SPIRV-Tools/pull/2923 after it is merged.


[Feature] Create expansions

Is your feature request related to a problem? Please describe.
It is very annoying to type the absolute path every time. If I want to select things from a user directory, I must provide the my absolute path + the directory name.
Example: What I need to do for selecting files in my current directory
SELECT ... FROM "<my-current-directory-absolute-path>"

Describe the solution you'd like
Bash & mostly all terminals uses environment variables that expand when we use it.
So, for example: $HOME becomes: The current user directory home.
Example: How could I select files in my current directory using expansion
SELECT ... FROM "$PWD"

Obs: $PWD expands to the current directory absolute path.

Could use the getenv function to retrieve values.
It is defined in the stdlib.h header.

[Bash doc](Shell Parameter Expansion) for shell parameter expansions.


Update jenkins dependency check plugin to 5.0.0-M2

The jenkins plugin is still on old version 4.0.2
Please update jenkins  plugin also to the latest available version 5.0.0-M2.
@stevespringett  Any idea on the timelines . Thanks

V5 isn’t released yet and m2 has known dependency issues with Jenkins and cannot be used. Also it’s a partial rewrite and major refactor. See https://groups.google.com/d/msg/dependency-check/2yMe6-Tg8tU/53SCfThcBQAJ


modified transceiver seems that it has a bug with chrome

Your environment.

Browser: chrome 108.0.5359.124
Other Information - stacktraces, related issues, suggestions how to fix, links for us to have context

What did you do?

What did you expect?
that ontrack event on addTranceiver side fires as intend
What happened?
when i do the following code in ontrack event
e.transceiver.direction = "sendrecv";
e.transceiver.sender
.replaceTrack(localStream.getAudioTracks()[0])
this doesn't trigger  ontrack event in yourConn side the caller
there is nothing received in the other side yourConn also that mean yourConn seem to not triggerd there
yourConn2.ontrack = (e) => {

           remoteVideo = document.getElementById("wbrtcremote");
           transceiversRemotePeer = new MediaStream([
             e.transceiver.receiver.track,
           ]);
           remoteVideo.srcObject = transceiversRemotePeer;
           console.log(
             `kind of this track that has arrived to remote peer is ${e.transceiver.receiver.track.kind}`
           );
           console.log("transceiversRemotePeer.receiver.track.onunmute");
           // remoteVideo.srcObject = e.streams[0].getAudioTracks()[0];

        //send backTrack

        e.transceiver.direction = "sendrecv";
        e.transceiver.sender
          .replaceTrack(localStream.getAudioTracks()[0])
          .then(() => {
             //check Tranciever
          let senderList = yourConn2.getSenders();
          let recieverList = yourConn2.getReceivers();
          console.log("recieverList in remotepeer is ", recieverList);
          console.log("senderList in remotepeer is ", senderList);
            console.log("Track replaced on transceiver's sender");
            console.log(
              "current direction in remotPeer after changing it is ",
              e.transceiver.direction
            );
          });
    };

but with addTrack used  it's triggers theres on yourConn side
yourConn2.addTrack(localStream.getAudioTracks()[0]);
configuration code for yourConn side to send and receive is :

          yourConn.addTransceiver(streams.getAudioTracks()[0]);

    yourConn.ontrack = (e) => {
     transceiversLocalPeer = new MediaStream([
          e.transceiver.receiver.track,
        ]);
        localVideo.srcObject = transceiversLocalPeer;
    }

behavior that happend with modified transceiver
yourConn after the call is done or connection is established just as fine
yourConn (the caller ) can send audio but not recieve
yourConn2 (the calle) can receive audio but can't send
ontrack event for yourConn => not triggered
ontrack event for yourConn2 => triggered

seems that modified tranciever doesn't trigger ontrack on addtranceiver side since there's no track added to connection


[material-ui][Slider][CssVarsProvider] Custom SliderThumb with CssVarsProvider is broken after upgrade @mui/material to 5.15.14

Steps to reproduce
Link to live example: (required)
Steps:

Go to https://stackblitz.com/edit/react-ceuj3r?file=Demo.tsx
You will see the position of SliderThumb is broken
Hover anywhere in the demo screen
You will see that '&:hover': { background: 'red' } has been applied to every elements

Current behavior
Position of the SliderThumb is broken

'&:hover': { background: 'red' } has been applied to every elements

Expected behavior
Position of the SliderThumb is correct

'&:hover': { background: 'red' } is only applied to SliderThumb

Context
I have a project that use CssVarsProvider and have a custom Slider. After I upgrade @mui/material to 5.15.14, the style is broken.
Your environment

npx @mui/envinfo
  System:
    OS: Windows 11 10.0.22631
  Binaries:
    Node: 20.10.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.2.3 - C:\Program Files\nodejs\npm.CMD
    pnpm: Not Found
  Browsers:
    Chrome: Not Found
    Edge: Chromium (123.0.2420.65)
  npmPackages:
    @emotion/react: ^11.11.4 => 11.11.4
    @emotion/styled: ^11.11.5 => 11.11.5
    @mui/base: 5.0.0-beta.40 => 5.0.0-beta.40
    @mui/core-downloads-tracker:  5.15.14
    @mui/icons-material: ^5.15.14 => 5.15.14
    @mui/material: ^5.15.14 => 5.15.14
    @mui/private-theming:  5.15.14
    @mui/styled-engine:  5.15.14
    @mui/system: ^5.15.14 => 5.15.14
    @mui/types:  7.2.14
    @mui/utils:  5.15.14
    @mui/x-charts: ^7.1.0 => 7.1.0
    @mui/x-data-grid:  6.19.8
    @mui/x-data-grid-premium: ^6.19.8 => 6.19.8
    @mui/x-data-grid-pro:  6.19.8
    @mui/x-date-pickers:  5.0.20
    @mui/x-date-pickers-pro: ^5.0.20 => 5.0.20
    @mui/x-license-pro:  6.10.2
    @types/react: ^18.2.74 => 18.2.74
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^5.4.3 => 5.4.3

Search keywords: CssVarsProvider, Slider, SliderThumb

can you assign this to me

After upgrading to 5.15.17 the position has been fixed, but '&:hover': { background: 'red' } still applies to every elements.

It's interesting that it works well with ThemeProvider: https://stackblitz.com/edit/react-ceuj3r-qlzp31?file=Demo.tsx or without any theme provider: https://stackblitz.com/edit/react-ceuj3r-ybpmz3?file=Demo.tsx. It seems to be an issue specifically with CssVarsProvider.

It's interesting that it works well with ThemeProvider: https://stackblitz.com/edit/react-ceuj3r-qlzp31?file=Demo.tsx or without any theme provider: https://stackblitz.com/edit/react-ceuj3r-ybpmz3?file=Demo.tsx. It seems to be an issue specifically with CssVarsProvider.

What is the current plan for CssVarsProvider?
My code currently uses a lot of theme.vars, so I cannot change back to ThemeProvider easily.
I cannot upgrade @mui/x-data-grid-premium to version 7 because it requires @mui/material at least v5.15.14.

I tried to debug it and noticed that the :hover effect is being applied globally. Here's a screenshot for reference:

However, I couldn't determine why this is happening. @siriwatknp, could you take a look?
As a temporary workaround to unblock your upgrade (if it's crucial to upgrade @mui/x-data-grid-premium to version 7), you could try using the slider's thumb class:
const StyledSlider = styled(Slider)(() => {
  return {
    [`& .${sliderClasses.thumb}`]: {
      '&:hover': {
        background: 'red',
      },
    },
  };
});

You can find the StackBlitz example here.

I noticed that if it is used as a standalone component it doesn't have the issue, e.g. example. I am taking a look at the changes between versions.

I found the issue, it was a wrong CSS value, that ended with "}" which broke the next CSS selector. I will cherry pick to master too, so we can release it next week.
To the original question, @vimutti77 it's safe to use the CssVarsProvider, we are stabilizing the API in v6. This issue was not related to it not working, it was a wrong CSS value in the component itself. Honestly, took me two hours to dissect the wrong line that produced this 😅


Add linux dependencies to README.md

This PR is in response to the following issue #246

I like the call out. Can we add this to the "Getting Started" section of the readme instead, right after: We recommend checking out The Bevy Book for a full tutorial. And make it refer generically to "setup".
Something like "Follow the Setup guide to ensure your development environment is setup up correctly."


fix broken expression-browser link

@brian-brazil This link is broken: https://prometheus.io/docs/visualization/expression-browser
on this page: https://prometheus.io/docs/guides/node-exporter/

(aka the expression browser).

So I corrected to : https://prometheus.io/docs/visualization/browser/

Can you add the DCO?

@brian-brazil Just added DCO. Could you please confirm?

Thanks!


feat(./postinstall-debug-package/postinstall.ts): add getInstallationPath() function

To fix the getInstallationPath() function, we need to correctly detect in yarn and pnpm whether the postinstall script was run when installing a dependency on a submodule in workspaces.
In other words, we should fix the expression of the isWorkspacePackage variable.
https://github.com/sounisi5011/nodejs-package-managers-debug--postinstall-script/blob/a14afb08547e972c725e8412b09cac6ce5d468ac/postinstall-debug-package/utils/get-installation-path.ts#L57-L59
yarn and pnpm do not include workspaces/true in the npm_config_user_agent environment variable.
pnpm seems to add the npm_config_workspace_root environment variable instead.
On yarn, it is probably not possible to detect this from the environment variables.


Cloud9

C9.io
Free tier: App Hosting (Node/Webstack/WordPress..)
Pros: Decent power for free plans + fair upgrades. Own subdomain. Web IDE + Console.
Limitations: SSH access but no root.

Thanks, will try to integrate this in the coming days :)

Haha glad to be able to contribute :)

solved


Adds demo/preview images to reference page

Updates the reference page to include a grid of images related to the specified model.
I'm not sure this is what we want, but I figure I would propose this as a possibility. Still some things can/need to be done:

maybe we can roll up those two components into 1? ModelList.js and ModelListCards.js
maybe also need to define a consistent style for the images? right now it is a motley blend!
Need to add Link A tag to image if not already.

Happy to hear thoughts and opinions on this @wenqili,  @shiffman

I love this idea! A couple quick thoughts:
I think it would nice to organize into three categories, something like. . . .

images, words, sounds
image, text, sound
pixels, characters, sounds

At some point we probably need a fourth category for multi-purpose things that you train? At the moment this is just the FeatureExtractor (which only works for images so can stay there fow now) and KNNClassifier.  I have no idea what to call this category! Any ideas?
@joeyklee would sorting into categories work with this design idea?
Also, let's use something less gender normative for word2vec, how about cat + puppy - dog = kitten?

I love this idea! A couple quick thoughts:
I think it would nice to organize into three categories, something like. . . .
* images, words, sounds

* image, text, sound

* pixels, characters, sounds

Yep, these are friendly categories :)

At some point we probably need a fourth category for multi-purpose things that you train? At the moment this is just the FeatureExtractor (which only works for images so can stay there fow now) and KNNClassifier. I have no idea what to call this category! Any ideas?
@joeyklee would sorting into categories work with this design idea?

Yes, I think so. Each model/feature can accept tags in the yaml frontmatter, so I think once we tag each of the models, then we can arrange the display as such. It will take a little tweaking, but it can be done!

Also, let's use something less gender normative for word2vec, how about cat + puppy - dog = kitten?

Yes, totally. This is great. I'll update the images.

At some point we probably need a fourth category for multi-purpose things that you train? At the moment this is just the FeatureExtractor (which only works for images so can stay there fow now) and KNNClassifier. I have no idea what to call this category! Any ideas?

In the future, when we have more models, maybe we can group them further into 3 subcategories?

image

pre-trained: mobileNet, darkNet, postNet, YOLO, UNET, styleTransfer, pix2pix, CVAE
re-train/transfer learning: FeatureExtractor, KNNClassifier
create & train your own model: imageClassifier

Or maybe just add another category called transfer learning? Let's talk more about it when we have more models.

For now I will merge this in and we can update/adjust as we see fit! Thanks!


Soft Keyboard

App works great!
We would like to disable the soft keyboard from appearing when we are in a 'scanning' screen using the package to capture barcodes.  Can we disable the soft keyboard from appearing within the package when a scan occurs?
Thanks for your time.

Can we disable the soft keyboard from appearing within the package when a scan occurs?

No

this have alternative solution?


Changed the background color of the team section

Description
The previous background color of the team section was a little dark, changed it to a lighter tone which is looking better!
Fixes #525
List any dependencies that are required for this change
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
UI /UX changes
Attach gif or screenshot for changes.

Before :
- After :

Checklist:

[ ] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Kindly sync your repo with the master branch.

After that?
On Sat, May 29, 2021, 8:53 PM Harikesh Pallantla @.***>
wrote:

Kindly sync your repo with the master branch.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Algo-Phantoms/Algo-Phantoms-Frontend/pull/526#issuecomment-850850826,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQDKGV4WUGN6AIBQ5Z5JCALTQEBIHANCNFSM45YFL7HA
.

After that?
…
On Sat, May 29, 2021, 8:53 PM Harikesh Pallantla @.***> wrote: Kindly sync your repo with the master branch. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#526 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQDKGV4WUGN6AIBQ5Z5JCALTQEBIHANCNFSM45YFL7HA .

After syncing your repo if all is good, we will merge the PR.

Resolve in #531


feat: Add Dark Theme

Codecov Report

Merging #223 into master will decrease coverage by 1.23%.
The diff coverage is 20%.

@@            Coverage Diff             @@
##           master     #223      +/-   ##
==========================================
- Coverage   48.27%   47.03%   -1.24%
==========================================
  Files          22       22
  Lines         290      287       -3
  Branches       57       58       +1
==========================================
- Hits          140      135       -5
- Misses        113      114       +1
- Partials       37       38       +1

Impacted Files
Coverage Δ

src/js/libs/colors.js
100% <ø> (ø)
:arrow_up:

src/js/components/Window/Title.js
8.33% <0%> (ø)
:arrow_up:

src/js/components/Tab/TabContent.js
20% <0%> (-1.43%)
:arrow_down:

src/js/components/Tab/Url.js
100% <100%> (ø)
:arrow_up:

src/js/components/Tab/Tab.js
7.5% <20%> (-8.78%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 15b3468...98ac8fa. Read the comment docs.

Coverage decreased (-0.8%) to 40.98% when pulling 98ac8fa0022af9130ef2f0587d309913d848ec8e on theme into 15b3468f4f884198911924d42a7f1b35e790b4da on master.


WSL terminating kali before it can install a package or a tweak

Windows Version
Microsoft Windows [Version 10.0.22631.3880]
WSL Version
<IP_ADDRESS>
Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>-2
Distro Version
Kali Linux 2024.2
Other Software
No response
Repro Steps
Try to download something with this same setup.
Expected Behavior
The files get downloaded and everything is ok.
Actual Behavior
Powershell/CMD Terminate it before it can finish, and then it returns to just a normal Powershell/CMD window.
Diagnostic Logs
No response

I think that that logs thing is outdated, it wont open

Turns out that bitdefender locked down my pc.

WslLogs-2024-07-27_15-00-48.zip

#7905 is not the same

Oh

Well how exactly do I get that?

It broke again

Turns out, I just needed to update it. everything is working smoothly now


Flashing error with latest idf under OsX (IDFGH-2177)

Development Kit:      [none]
Module or chip used:  [ESP32-WROVER-B]
IDF version (run git describe --tags to find it):
v4.1-dev-815-ga45e99853
Build System:         [CMake]
Compiler version (run xtensa-esp32-elf-gcc --version to find it):
xtensa-esp32-elf-gcc (crosstool-NG esp32-2019r1) 8.2.0
Operating System:     [macOS]
Power Supply:         [external Battery]

Unable to program after updating all the ESP tools.
esptool.py -p /dev/cu.SLAB_USBtoUART -b 460800 --after hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 16MB 0x8000 partition_table/partition-table.bin 0xd000 ota_data_initial.bin 0x1000 bootloader/bootloader.bin 0x10000 calimotion.bin
esptool.py v2.9-dev
Serial port /dev/cu.SLAB_USBtoUART
Connecting........___
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:0a:c4:47:54:b4
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Compressed 3072 bytes to 136...
A fatal error occurred: Timed out waiting for packet content
esptool.py failed with exit code 2
--- Build failed
--- Press Ctrl+] to exit monitor.
--- Press Ctrl+F to build & flash project.
--- Press Ctrl+A to build & flash app.
--- Press any other key to resume monitor (resets target).
Trying to program same board than before fail with the latest build.

Hi @Francois-Belanger,
The failure indicates most likely a hardware issue (could be power supply or serial signal integrity.)
If you set the baud rate back to something lower (the old default was 115200bps), does it start working?
Angus

I will redo some tests.

Power supply is very stable at 3.0V
Uarts lines all clean.
Could it be an issue with the build ?  Bad file in my build directory ?  Bad config ?
I was using the WROVER fine on the same boards, just change it to WROBER-B and it doesn't work anymore...

ok, found the issue.  It's line MTDI that was at logic 1 instead of 0.
Thanks for the help.


Create View "Complexity Evaluation"

User story

As a consultant
I want a complexity evaluation
So that I can assess which products are too complex

Acceptance criteria

Contains list of all question categorizes by questionnaire name
Shows
- Complexity rating (colorized)
- Comment
- Sources / Documentation
from #64
Contains field for additional comments
Contains option to save and go back to product overview
Contains option to cancel and go back to product overview

Definition of done

Added only after week 5
The same for all features


[Impeller] non-uniform image filter blurs don't render correctly

Looks like we may be duplicating the sigma to make it uniform at some point.  Things seem to render correctly at the renderer level.
expected result

seen result

reproduction code

code
import 'dart:math';
import 'dart:ui';

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  double rotate = 0.0;

  Widget makeRow(double cornerSize, double blurSize) {
    return Row(
      mainAxisAlignment: MainAxisAlignment.spaceEvenly,
      children: <Widget>[
        CustomPaint(
          painter: _RRectPainter(
            cornerSize: cornerSize,
            blurSize: blurSize,
            scale: 0.5,
            rotate: rotate,
          ),
          size: const Size(150, 150),
        ),
        CustomPaint(
          painter: _RRectPathPainter(
            cornerSize: cornerSize,
            blurSize: blurSize,
            scale: 0.5,
            rotate: rotate,
          ),
          size: const Size(150, 150),
        ),
        CustomPaint(
          painter: _RRectPainter(
            cornerSize: cornerSize,
            blurSize: blurSize,
            scale: 1.0,
            rotate: rotate,
          ),
          size: const Size(150, 150),
        ),
        CustomPaint(
          painter: _RRectPathPainter(
            cornerSize: cornerSize,
            blurSize: blurSize,
            scale: 1.0,
            rotate: rotate,
          ),
          size: const Size(150, 150),
        ),
      ],
    );
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        backgroundColor: Theme.of(context).colorScheme.inversePrimary,
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.spaceEvenly,
          children: <Widget>[
            makeRow(10, 10),
            makeRow(10, 30),
            makeRow(10, 50),
            Row(
              mainAxisAlignment: MainAxisAlignment.center,
              children: <Widget>[
                const Text('rotation'),
                Slider(
                  value: rotate,
                  min: 0.0,
                  max: pi * 2.0,
                  onChanged: (value) {
                    setState(() {
                      rotate = value;
                    });
                  },
                ),
              ],
            ),
          ],
        ),
      ),
    );
  }
}

class _RRectPainter extends CustomPainter {
  _RRectPainter({
    required this.cornerSize,
    required this.blurSize,
    required this.scale,
    required this.rotate,
  });

  final double cornerSize;
  final double blurSize;
  final double scale;
  final double rotate;

  @override
  void paint(Canvas canvas, Size size) {
    canvas.translate(size.width * 0.5, size.height * 0.5);
    canvas.rotate(rotate);
    canvas.translate(-size.width * 0.5, -size.height * 0.5);

    canvas.scale(scale, scale);
    double w = size.width / scale;
    double h = size.height / scale;
    double c = cornerSize / scale;

    Rect rect = Rect.fromLTRB(0, 0, w, h);
    RRect rrect = RRect.fromRectXY(rect, c, c);

    Paint paint = Paint()
      ..imageFilter = ImageFilter.blur(sigmaX: blurSize, sigmaY: 0.0, tileMode: TileMode.decal)
      // ..maskFilter = MaskFilter.blur(BlurStyle.normal, blurSize)
      ..color = Colors.blue;
    canvas.drawRRect(rrect, paint);
  }

  @override
  bool shouldRepaint(covariant CustomPainter oldDelegate) => true;
}

class _RRectPathPainter extends CustomPainter {
  _RRectPathPainter({
    required this.cornerSize,
    required this.blurSize,
    required this.scale,
    required this.rotate,
  });

  final double cornerSize;
  final double blurSize;
  final double scale;
  final double rotate;

  @override
  void paint(Canvas canvas, Size size) {
    canvas.translate(size.width * 0.5, size.height * 0.5);
    canvas.rotate(rotate);
    canvas.translate(-size.width * 0.5, -size.height * 0.5);

    canvas.scale(scale, scale);
    double w = size.width / scale;
    double h = size.height / scale;
    double c = cornerSize / scale;

    Path path = Path();
    path.addRect(Rect.fromLTRB(c, 0, w - c, h));
    path.addRect(Rect.fromLTRB(0, c, w, h - c));
    path.addOval(Rect.fromLTRB(0, 0, c * 2, c * 2));
    path.addOval(Rect.fromLTRB(w - c * 2, 0, w, c * 2));
    path.addOval(Rect.fromLTRB(0, h - c * 2, c * 2, h));
    path.addOval(Rect.fromLTRB(w - c * 2, h - c * 2, w, h));

    Paint paint = Paint()
      ..imageFilter = ImageFilter.blur(sigmaX: blurSize, sigmaY: 0.0, tileMode: TileMode.decal)
      // ..maskFilter = MaskFilter.blur(BlurStyle.normal, blurSize)
      ..color = Colors.blue;
    canvas.drawPath(path, paint);
  }

  @override
  bool shouldRepaint(covariant CustomPainter oldDelegate) => true;
}

doctor
[!] Flutter (Channel [user-branch], 3.23.0-13.0.pre.27, on macOS 14.5 23F79 darwin-arm64, locale en)
    ! Flutter version 3.23.0-13.0.pre.27 on channel [user-branch] at /Users/aaclarke/dev/flutter
      Currently on an unknown channel. Run `flutter channel` to switch to an official channel.
      If that doesn't fix the issue, reinstall Flutter by following instructions at https://flutter.dev/docs/get-started/install.
    ! Upstream repository unknown source is not a standard remote.
      Set environment variable "FLUTTER_GIT_URL" to unknown source to dismiss this error.
    • Framework revision 472a29d3f3 (31 hours ago), 2024-05-30 09:24:14 -0700
    • Engine revision fb64b9a4e6
    • Dart version 3.5.0 (build 3.5.0-203.0.dev)
    • DevTools version 2.36.0-dev.10
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

cc @flar (discovered by him in https://github.com/flutter/engine/pull/53130)

Here is a reduced reproduction:

import 'dart:math';
import 'dart:ui';

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  double rotate = 0.0;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.spaceEvenly,
          children: <Widget>[
            CustomPaint(
              painter: _RRectPainter(
                cornerSize: 10,
                blurSize: 50,
                scale: 1.0,
                rotate: (180.0 * 45.0) / pi,
              ),
              size: const Size(150, 150),
            ),
          ],
        ),
      ),
    );
  }
}

class _RRectPainter extends CustomPainter {
  _RRectPainter({
    required this.cornerSize,
    required this.blurSize,
    required this.scale,
    required this.rotate,
  });

  final double cornerSize;
  final double blurSize;
  final double scale;
  final double rotate;

  @override
  void paint(Canvas canvas, Size size) {
    canvas.translate(size.width * 0.5, size.height * 0.5);
    canvas.rotate(rotate);
    canvas.translate(-size.width * 0.5, -size.height * 0.5);

    canvas.scale(scale, scale);
    double w = size.width / scale;
    double h = size.height / scale;
    double c = cornerSize / scale;

    Rect rect = Rect.fromLTRB(0, 0, w, h);
    RRect rrect = RRect.fromRectXY(rect, c, c);

    Paint paint = Paint()
      ..imageFilter = ImageFilter.blur(
          sigmaX: blurSize, sigmaY: 0.0, tileMode: TileMode.decal)
      ..color = Colors.blue;
    canvas.drawRRect(rrect, paint);
  }

  @override
  bool shouldRepaint(covariant CustomPainter oldDelegate) => true;
}

If you run the EntityTest.GaussianBlurFilter it rotates the one dimensional image filter correctly.

The difference appears to be that in the flutter case the input snapshot includes the rotation already.  In the entity test the input is a texture that is never rotated:

Instead of doing tomfoolery in the blur to account for the blur I would like to instead have a way to get an axis aligned snapshot and handle the rotation in the resulting entity's transform.


Add subscribe_rhel to only vmw

-Reverted the rhel_subsribe to work for VMware
-Added compatibiilty with the shared roles
-Fixed playbook issue caused by add-node pr

aos-vmw-test

Lgtm


making af_activeRequestReceipt public

What do you think about the idea of making this public?
I think it would be useful to cancel off existing requests. Unlike Alamofire where you get a Request returned, AlamofireImage doesn't have any way of cancelling existing requests.
I considered the af_setImageWithUrl returning the receipt but it would just be easier to use the existing var.
Basically this is related to a problem I had a while ago where I had to skirt around AlamofireImage to cancel off a request if the image is too big (it was crashing my share extension). My solution is this:
request = Alamofire.request(.GET, url).responseImage(completionHandler: { [weak self] response in

                switch response.result {
                case .Success(let image):
                    self?.imageView.si_transitionImage(image)
                    completion(completed: true)
                case .Failure(let error):
                    completion(completed: false)
                }
            }).progress({ [weak self] _, _, totalExpected in
                if totalExpected > Int64(Image.maxImageSize) {
                    self?.request?.cancel()
                }
            })

With the new progress support on af_setImage I could do the same thing and leverage AlamofireImage to cancel off my request.

Hi @JamieWhite,
You can already cancel an active image request using the af_cancelImageRequest API. That should be everything you need.
Cheers. 🍻

Hah. Sorry. RTFM


Error   on tryin to install v0.24.0 with cargo install contracts-node

thread 'main' panicked at 'Could not find protoc  installation and this build crate cannot proceed without this knowledge.it seems compiling failed

You need to install the protobuf compiler as explained in the substrate compilation guide.

Sorry, but on 'https://use.ink/basics/contract-testing/' "protoc" isn't mentioned anywhere (and there is no link to the substrate compilation guide). This is annoying.


How to implement revoke certificate in Plugin

I did not see any way to revoke certificate in the lemur plugins interfaces.
I guess this is the job of the active/inactive button on the UI, but have not seen a way to implemented it.

How i show to the user error from plugin, except from Internal Server error with raising Exception.

There is no current support for revocation in Lemur. We largely use Lemur as a self-service portal for developers and it was determined that revocation was a high risk activity we would not generally expose. Combined with the use of short-lived certificates and infrequency of revocation means that adding support was low value.
That being said I am open to contributions in this area.
What kind of error are you considering showing the user, validation error or something else?

So the active certificate is just indicator not a button to revoke?
I would like to show validation errors to the users.

Yes, the active button is just a record keeping action and controls which certificates receive notifications.
For validation errors you can always raise a custom exception raise Exception('This is your error') this will message will be propagated back to the user.
For example:
https://github.com/Netflix/lemur/blob/master/lemur/plugins/lemur_verisign/plugin.py#L128
Dynamically raises the API error and gives a helpful message to the user. But this would be after the fact.
If you are looking at providing feedback to a user in JS before request is submitted you can do something like:
https://github.com/Netflix/lemur/blob/master/lemur/plugins/lemur_aws/plugin.py#L52
Where the validation is a simple regex on the input value. They will then be shown the error as they are typing the value into the input.

I tried to raise Exception but it just showed Internal Server Error in the ui, for example:
https://github.com/RcRonco/lemur_vault/blob/master/lemur_vault/plugin.py#L50
The options dictionary is not an option for issuer plugin?

Ah, you are correct it will result in a Internal Server Error with  500 status code. It should however correctly show your message. Is that not the case?

It's not my case it just show red message with Internal Server error.
I would like to show error on wrong parameters that plugins get, like TTL of certificate is too high.

Can you see if there is any more detail in the response? If you look inside chrome's inspector for instance, in the network details you should be able to see the whole response.

The result of this line:
https://github.com/RcRonco/lemur_vault/blob/master/lemur_vault/plugin.py#L50
Is the picture below, i can not expect my users to  check with the developer console what wrong with their input.

What is the the stack trace in the lemur.log? My guess is that you're hitting a different error, not the one expecting.

In the stack trace I see the expected exception message.

Can you post the stacktrace?

Sure I will post it tomorrow

Traceback (most recent call last):
  File "/www/lemur/lemur/common/schema.py", line 136, in decorated_function
    resp = f(*args, **kwargs)
  File "/www/lemur/lemur/certificates/views.py", line 233, in post
    return service.create(**data)
  File "/www/lemur/lemur/certificates/service.py", line 214, in create
    cert_body, private_key, cert_chain = mint(**kwargs)
  File "/www/lemur/lemur/certificates/service.py", line 158, in mint
    cert_body, cert_chain = issuer.create_certificate(csr, kwargs)
  File "/www/lemur/lemur/plugins/lemur_vault/plugin.py", line 98, in create_certificate
    raise Exception('Vault Test')
Exception: Vault Test
Internal Error
Traceback (most recent call last):
  File "/www/lemur/lemur/common/schema.py", line 136, in decorated_function
    resp = f(*args, **kwargs)
  File "/www/lemur/lemur/certificates/views.py", line 233, in post
    return service.create(**data)
  File "/www/lemur/lemur/certificates/service.py", line 214, in create
    cert_body, private_key, cert_chain = mint(**kwargs)
  File "/www/lemur/lemur/certificates/service.py", line 158, in mint
    cert_body, cert_chain = issuer.create_certificate(csr, kwargs)
  File "/www/lemur/lemur/plugins/lemur_vault/plugin.py", line 98, in create_certificate
    raise Exception('Vault Test')
Exception: Vault Test

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/www/lemur/lib/python3.5/site-packages/flask/app.py", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/www/lemur/lib/python3.5/site-packages/flask/app.py", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/www/lemur/lib/python3.5/site-packages/flask_restful/__init__.py", line 462, in wrapper
    resp = resource(*args, **kwargs)
  File "/www/lemur/lib/python3.5/site-packages/flask/views.py", line 84, in view
    return self.dispatch_request(*args, **kwargs)
  File "/www/lemur/lib/python3.5/site-packages/flask_restful/__init__.py", line 572, in dispatch_request
    resp = meth(*args, **kwargs)
  File "/www/lemur/lemur/auth/service.py", line 111, in decorated_function
    return f(*args, **kwargs)
  File "/www/lemur/lemur/common/schema.py", line 139, in decorated_function
    return dict(message=e.message), 500
AttributeError: 'Exception' object has no attribute 'message'

This was fixed in 0.4. Please make sure you have that release:
https://github.com/Netflix/lemur/commit/b74df2b3e407fcda10259f6d612d846ca1b9a47b


Stop reconciliation and clustering

refs:
https://github.com/cybozu-go/moco/issues/572
https://github.com/cybozu-go/moco/issues/564
Add the enhancement to stop clustering and reconciling MySQLCluster based on the following design document.
https://github.com/cybozu-go/moco/blob/main/docs/designdoc/clustering_stop.md

I have added functionality to display messages when stopping or resuming clustering and reconciliation using the kubectl moco command.
https://github.com/cybozu-go/moco/pull/578/commits/41076822eb1b6be4a3c8e4022ae29c81ca849656

LGTM
However, I would like to wait for a review of zoetrope.

@zoetrope
Thanks for the comment. I have fixed it with the following commit.
https://github.com/cybozu-go/moco/pull/578/commits/75572b773eea65d41c2bc6554013cdeef5a82ac4


Include expected patterns and tooltips in self registration forms

Is your suggestion related to an experience ? Please describe.
In the self registration process, the username form and the registration form do not include any tool tips or examples for the patterns they are expecting in each input field. Considering a self registering user will not be an administrator, each end user having to go through the documentation to understand the expected patterns and inputs reduces the user experience.
eg:

Invalid username entry gives, "Username pattern policy violated" error message. But The expecting pattern is not specified.
Invalid phone number in registration gives "Please match requested format" warning. But the requested format in not specified in the form
No example for IM field or URL field to understand what to input.

Describe the improvement
Include tooltips or placeholder examples where necessary

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


install.sh should get client nightlies

This is technically an omnitruck issue.
Currently Omnitruck and the install.sh script differentiate between stable, nightly, and "pre" releases. We've overloaded the version of the package similar to Rubygems for this functionality. I believe stable releases are numerical, pre-releases are alpha-numeric, and nightlies have a git sha in them. This is noted in the the omnitruck readme as well.
In the near future, we're going to regularly produce builds, as often as every time something goes into master, or at least daily (providing something changed). We've discussed calling these "integration builds."
Currently you get unexpected results when you ask for a nightly (you get a really old build) but you get something newer if you ask for a pre-release nightly. We should simplify all this into just being stable releases and integration builds.

Bryan McLellan: I had a talk with @schisamo and I'd like to change omnitruck for the chef-client to just have "releases" like you normally get, and "integration builds" which could be nightlies, or a prerelease or any other build that you publish that isn't a promoted release. anyone have feelings about this?
Lamont Granquist: well, it already has both nightlies and prereleases
Lamont Granquist: so can you get what you want out of what is already there?
Bryan McLellan: it has nightlies, prereleases, and nightly prereleases, all based on voodoo in the version string, and currently install.sh/omnitruck/manhattan disagree about at least one of those definitions. so we want to make all of those be one thing.
Lamont Granquist: okay, that sounds like something i'm +1 on
Lamont Granquist: while you're at it, -p and -n are exclusive and won't serve up releases, so if there's a more recent actual release and you supply -p you won't see it, which is not what anyone wants
Bryan McLellan: yeah the omnitruck readme is explicit about that, so it's probably a fix in omnitruck as well.
Lamont Granquist: yeah, i had a branch that implemented that, but it broke about a thousand spec tests in the process

We'll want to set up a second Omnitruck instance for serving up integration/nightly builds. This would allow us to have two distinct Omnitruck channels, one for current builds and one for stable builds. This would also map directly to how we handle the publishing to PackageCloud which has two distinct channels/repos:
https://packagecloud.io/chef/current
https://packagecloud.io/chef/stable

In effect, I believe you're arguing that remove all Omnitruck functionality where it differentiates between types of builds by filename, and have the install.sh script / MSI links use a different URL for fetching different packages? That's a little different than just combining Omnitruck's current idea of pre-release versus nightly.
I think we'd want to have the stable instance return a 301 if nightlies or prerelease is true, for compatibility for anyone using the API. Or an 500 error at least. Something less confusing than ignoring it.

Two omnitruck instances sounds like a really bad idea to me.   We have the ability to support different projects already which are similar to channels with -P chef-server and -P chefdk.  The additional overhead of managing more instances seems unnecessary.
We can take the existing omnitruck instance and add more channels like 'chef-stable' and 'chef-current' or we can add another flag which switches between stable and current subdirs in the metadata bucket.  That way we don't have to increase the infrastructure footprint of omnitruck and the management overhead and add more URLs and increase the confusion and likelihood of operational mistakes.

I don't care how we achieve 2 distinct channels in Omnitruck (multiple instances, multiple buckets etc.) but a couple of things to think about as you design the solution/api/architecture:

As we move to a pure continuous delivery world we'll stop creating special ceremonial stable builds (with special version numbers). Essentially any build is a candidate for being blessed as stable. In this world, we won't be able to use the package's version number to determine it's channel categorization. Many Chef Software, Inc. projects (Chef Server, Management console etc) are already beginning to experiment with using build versions like: MAJOR.MINOR.PATCH+YYYYMMDDHHMMSS.
Pre-releases (alphas, betas, RCs etc) will most likely become a thing of the past as we will have many end-users (including Chef Software, Inc.) dog fooding builds from the 'current' channel.
We're about to move the publishing to Omnitruck from Jenkins to Artifactory. This will ensure all of our external consumption points (PackageCloud, Omnitruck etc.) are all published to at the same time and adhere to the same promotion logic. Publishing to Omnitruck will work in the same way publishing to PackageCloud currently works:

There is a 1:1 mapping between an Artifactory repo and an associated external channel (e.g. omnibus-current-local -> PackageCloud chef/current, omnibus-stable-local -> PackageCloud chef/stable)
An Artifactory user plugin responds to Artifactory publish events and pushes (and yanks) artifacts to the external system appropriately.

So omnitruck already has the same kind of internal structure.  The opscode-omnibus-package-metadata bucket holds different subdirs which are like different channels when then have all the individual metadata json blobs.  The artifacts are stored separately in opscode-omnibus-packages.
Omnitruck wouldn't have a problem with having something like:
opscode-omnibus-package-metadata/chef-current/12.3.0+20150417120000.json pointing at s3://opscode-omnibus-packages/ubuntu/14.04/x86_64/chef-12.3.0+20150417120000.json and then to do a release to stable all you do is upload a new opscode-omnibus-package-metadata/chef-stable/12.3.0+20150417120000.json blob pointing at the same artifact.  Essentially the metadata blobs give you symlinks.

@schisamo So do current builds get MAJOR.MINOR.PATCH+YYYYMMDDHHMMSS but stable channel builds will always be just a version? Is this how chef-trigger-release versus chef-trigger-anything_else currently works in manhattan?
If not:
If there's nothing in the version that differentiates between stable and current builds... when we want to promote a build to stable are we going to ask people to test whatever the latest build from current is (instead of an RC)?
It feels like it's going to be a little frustrating when someone has an issue and they tell support (or IRC, or whoever) that they're running chef-12.3.0+20150417120000, if that build had a small bug and we shortly after made another build chef-12.3.0+20150417122000 and that one was promoted to stable. You're going to want to tell someone to upgrade to the latest something, but people don't always want to upgrade to the very latest release.

@schisamo I think the technical options for exposing two channels so someone can run "install.sh --give-me-the-edge" and get what they want are all in here, and we're probably shed-building past this point.
Once https://github.com/chef/chef-rfc/issues/115 gets accepted, someone from releng should open a PR against it to propose whatever versioning scheme you've come up with. I don't want to surprise the community with a significant change in how releases are versioned and treated.

I vote for keeping things simple here and making it easy for us to just get started -- if a new omnitruck for "current" is easy to do, can we just go with that and iterate? Here's what I'd like to see:

One convention for categorizing releases (e.g. "stable" vs "current") across all Chef Software releases ("products")
One way for users to choose from those categories across release points (e.g. omnitruck vs. packagecloud)
Start on a path that makes it easy for projects to use Delivery
An easy was for us to just get started and take a baby step

I think having omnitruck support an explicit "current" and "stable" channel with different URI's / implementations will do that and would let us get up and running faster (existing omnitruck would just be stable, and we could experiment with a new one for current without disrupting stable). .
I could live with a single omnitruck and a query parameter for stable vs. current (the first two bullets), but I don't relish the idea of changing that public endpoint while we're this early in the game.
Worst case we learn that it's better for users to have one omnitruck, but in the short term I think tossing another one out there is pretty easy, right @schisamo?
@btm, I hear you on the version concerns, but again, I'd like to see people hit issues here and then we take action, which should be pretty fast. Also, it may be that versioning methodologies get "forced" on us initially as we move to using Delivery in more places.
We can always change things later folks. :smile:.

@adamedx I'm not sure what you mean by vision, but my concern is that Chef Software decides how Chef Client is going to be versioned internally, ships it, and waits for people to have issues before starting a discussion with them.
For example, just talking about versioning on https://github.com/chef/chef-rfc/pull/115 has already exposed that @jaymzh has encountered upgrade issues with our current versioning scheme with rpm packages.
Discussing it publicly both makes it more complete, and makes us good members of the community.

@btm, maybe I'm not getting it, but is there a new versioning scheme being proposed for the current omnitruck? If we have a new omnitruck, versions aren't affected, right?

I'd second the importance of having this discussion in the open so to speak to surface potential issues before they bite people.
On a more general note about the continuous delivery of releases, it bears remembering that although builds will indeed be delivered continuously and this is a good thing, they will often not be consumed that way.
When doing CD inside a company for example, you're often going to be deploying the latest release into production at any one time. This does not map to the way people typically deploy chef releases - some people will be relatively bleeding edge, some people will still be trying to finish migrating to 12.x full stop (we're one of those cases), and you will often find a large delta between the chef-client versions people deploy in production. Often, a new release will only be consumed by a customer because it scratches a particular itch or adds a new feature.
When we're looking at how to implement this on the omnitruck side, my gut reaction is to favour separate stable and current channels simply to make it as easy as possible to DWIM. As a consumer of chef releases, I'd like to be able to go to the stable channel and see "ah yes, this is the most recent stable 12.1 release, and here's the latest stable 12.3 release I want to upgrade to.".
As @schisamo said, we might not in future be able to use a version number to indicate stability, so that's mainly why it seems reasonable to me to have a channel where only builds blessed as stable exist. The actual build number doesn't matter, but I know that in that channel I will always find the latest stable 12.x.y.ZZZZZZ release. In the event that I do need a more current release that hasn't been marked as stable, I have the option of going to the "current" channel should I choose to.
Although debian stable & testing repos aren't exactly a model for continuous delivery, it's that sort of model I see as making the most practical distinction between whichever builds have been blessed as stable, and which are bleeding edge nightlies. That said, if there's a nice way to do this under one omnibus project then great, my main intent here is that we don't get too carried away with CD that we forget how said deliveries are typically going to be consumed.

FWIW, you can currently get a nightly build from the Omnitruck API: http://www.chef.io/chef/download?p=windows&pv=2008r2&m=x86_64&v=latest&prerelease=true&nightlies=true
Right now, this gives you chef-client-12.4.0-dev.0+20150501082811.git.48.b060c84-1.msi, which was built by http://manhattan.ci.chef.co/job/chef-build/102/ (internal link) by the nightly trigger.

I think this was mostly done in https://github.com/chef/opscode-omnitruck/pull/100, but the install.sh hasn't been updated to correspond yet and we haven't shipped those changes which have been merged.

That shipped yesterday.  Right now we do still differentiate between released versions and nightlies by their version number, and not by what channel they are in, but everything else works to get nightlies.

@lamont-granquist how do the existing -n and -p flags work with what just shipped? We used to have to pass both -n and -p to get what we expected as a "nightly".

Use either one, and you get whatever the latest is...  Even if the latest is a release, so its "additive" rather than exclusive.

I think this is closable now at least in this repo.  The nightlies work fine in omnitruck/install.sh now.
The only remaining problem is that omnibus-chef needs to be pointed at "master" or else the actual nightly builds themselves will just rebuild release tags -- which is a bug against omnibus-chef.


build: Use the most recent poetry version

Codecov Report

Merging #1354 (d0eb19b) into master (67577ff) will decrease coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1354      +/-   ##
==========================================
- Coverage   99.09%   99.01%   -0.09%
==========================================
  Files          83       83
  Lines        6316     6264      -52
  Branches     1088     1088
==========================================
- Hits         6259     6202      -57
- Misses         29       32       +3
- Partials       28       30       +2

Flag
Coverage Δ

unittests
99.01% <ø> (-0.06%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/schemathesis/extra/pytest_plugin.py
98.23% <0.00%> (-1.77%)
:arrow_down:

src/schemathesis/cli/callbacks.py
98.33% <0.00%> (-1.67%)
:arrow_down:

src/schemathesis/specs/openapi/loaders.py
98.31% <0.00%> (-0.85%)
:arrow_down:

...rc/schemathesis/specs/openapi/negative/__init__.py
94.11% <0.00%> (-0.17%)
:arrow_down:

src/schemathesis/serializers.py
98.18% <0.00%> (-0.11%)
:arrow_down:

src/schemathesis/runner/serialization.py
97.97% <0.00%> (-0.10%)
:arrow_down:

src/schemathesis/lazy.py
95.37% <0.00%> (-0.05%)
:arrow_down:

src/schemathesis/runner/impl/core.py
97.74% <0.00%> (-0.02%)
:arrow_down:

src/schemathesis/models.py
99.18% <0.00%> (-0.02%)
:arrow_down:

src/schemathesis/cli/__init__.py
98.39% <0.00%> (-0.01%)
:arrow_down:

... and 14 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 67577ff...d0eb19b. Read the comment docs.


Explore using the AWS Secrets Manager caching feature

AWS Secrets Manager has a caching library which updates the cache periodically, ensuring your applications use the most up to date secret value without polling.  If you run the init container as a sidecar and make use of this library it may eliminate the need for an operator that recycles the pod when a secret is rotated.  The downside is that it will require you to run a sidecar (increases the resource requirements) and your application will have to be written to re-read the password from disk when the secret is rotated.

If we rewrite the application, then I would suggest let the app directly read the secret and not use the Sidecar container. What do you think ?

@allamand When I say "re-write the application" I mean writing the application to re-read the secret from disk when an error occurs using the old secret.  I think that's an easier change than adding the AWS SDK to your application.  I'm open to being convinced otherwise.

Our current plan is to use a CRD an operator to patch the pods in a deployment that references a secret from AWS Secrets Manager when the secret is rotated.  The CRD will maintain a mapping between deployment:secret and will inform the operator which messages to act upon.  AWS Secret Manager events will be put into an SQS message queue which the operator will read from.  When the operator receives a message that indicates a password has been rotated, it will loop through the CRDs until it finds a matching deployment.  It will then patch that deployment which will cause the pods to restart and reload the secret.

Sounds reasonable.  Just to put it out there, I think you've described a "push" pod update mechanism.  Another approach might be "pull":
The operator could notify the sidecars when the new secret is available.  Eg: by just updating the proposed CRD with a timestamp or other generation number, then all sidecars 'watching' that CRD would go and fetch the latest secret value from AWS, and write it to the volume shared with the main container.
Pros: no need to find+restart Deployments.  Cons: sidecar needs a k8s watch on a new CRD.

@anguslees We were purposely trying to avoid polling because a) there could be a long wait between polling intervals causing the app to break and b) excessive polling could get expensive. We could add a listener to the sidecar that fetches the secret again when it receives a message from the controller or we could subscribe it to an SNS topic.  The downside is we'd need to create a topic for each secret or create a registry [CRDs] of sidecars that the controller would notify when the secret changed.  We could extend NASE to create an SNS topic.  I'll need to think about it.