infrastructure-as-code

Description

let's say I have an apache process group I want to control.

• when using supervisord.running, the name must be apache:* (which is the same notation used by supervisor)
• when using supervisord.dead, the name must be apache: (without the *)

As both states mirror each other, I expect them to use the same convention for name, the one from running since it

Currently, Trivy traverses all paths and looks for all Gemfile.lock in a container image. However, the image sometimes has only Gemfile.lock and doesn't install gems listed in the Gemfile.lock. I think a gem should have *.gemspec file if it is installed. e.g. rake.gemspec has the information about rake.

To avoid false positives from Gemfile.lock, we are probably able to take advantage of `*

On creating a VPC with existing EIP. It creates Natgateway with that EIP. But it also creates an additional EIP which is not associated with any resource.

Reproduction Steps

    subnet1 = SubnetConfiguration(
            name="Public",
            subnet_type=SubnetType.PUBLIC,
            cidr_mask=24)
    subnet2 = SubnetConfiguration(
            name

Requesting that you add the new Gitlab Provider as a new VCS Provider.

See here for the provider details: https://registry.terraform.io/providers/gitlabhq/gitlab/latest

Add package manager support for windoz users with chocolatey:
like here: https://github.com/bridgecrewio/yor-choco

Currently only AWS, GCP, and Azure is supported. It's great if Openstack support is added too, as most of on-premise clouds are based on that.

Hello,

Do you plan to support Terraform scans with OpenStack in the future ?

Regards

Copilot doesn't seem to have correct error behavior when I try to create a Scheduled Job with the same name as an existing service.

For example, in my app right now I have the following:

❯ copilot svc ls
Name                Type
----                ----
fe                  Load Balanced Web Service

I can see this in SSM:

❯ aws ssm get-parameter --name /copilot/applicatio

Garbage collection works by listing everything with the gc-tag. In a busy cluster, we really want that filter to happen server-side and ideally using an index of some sort.

That means we should use a Kubernetes label, not an annotation.

I think this will require a two-step migration plan (write both but continue to read annotation; release; drop support for annotation; release).