Problem to solve

Need to test PR template

Proposed solution

PR with this issue

Alternatives

none

Additional context

just a teest

https://github.com/trendmicro/cloudone-community/tree/main/Workload-Security/Deployment/aws-python-agent-deploy-automation-using-lambda

Describe the bug

Run Command document never leaves pending state. Instances are being tagged correctly but no agent is deployed.
No outputs were generated in the session.

To reproduce

Just deploy it and it should replicate itself. Found during WS immersion day.

Describe the bug

I've discussed this with @raphabot offline. Right now we (Contributors of the repository) don't have access to fork, it's disabled so the way to contribute is to create a branch push changes then make the PR to the main, the only issue is when we make it public this repository others that are not added as contributors, won't have access to contribute (I assume), since Fork is deactivated.

To reproduce

Steps to reproduce the behavior:

1. The button to fork the repo does not work and tells the message "Cannot fork because the fork is disabled"

Expected behavior

I imagine that fork should be enabled for other people to make contributions and also a good idea to enable it now so we can test and fine-tune different situations before launch.

Additional context

The documentation explicitly asks to use a Fork to make contributions, so better start with ourselves (In case not, we could fix the documentation instead) :

We accept contributions from the community. To submit changes:

Fork this repository.
Create a new feature branch.
Make your changes.
Submit a pull request with an explanation of your changes or additions.

A couple of points that I found that will be helpful for everybody in enabling Forks:

• We don't need to manage user access on your repository.
• We gain fine-grain control over merging.
• It expressly support independent branches.
• Discard and create experiments and changes easily.

Got it from here, I thought was helpful to better understand the pros and cons:

https://support.atlassian.com/bitbucket-cloud/docs/branch-or-fork-your-repository/

Describe the bug

The externalID key fails after FSS API call

Traceback (most recent call last):
  File "deploy.py", line 225, in <module>
    get_exclusions(filename)
  File "deploy.py", line 41, in get_exclusions
    get_buckets(content)
  File "deploy.py", line 59, in get_buckets
    get_encryption_region(list_of_buckets)
  File "deploy.py", line 116, in get_encryption_region
    deploy_storage(kms_arn, region, bucket_name)
  File "deploy.py", line 147, in deploy_storage
    ext_id = json.loads(r.data.decode("utf-8"))['externalID']
KeyError: 'externalID'

Describe the bug

Update the README to direct the right topics between the Issues and the GitHub Discussions

Additional context

With the launch of the community in the GitHub discussions, all "discussions/Q&A" topics must be taken to GitHub discussions over Issues, the README should reflect this information to all members

Describe the bug

Any new PR will not be synced with S3 so we can test before the merge.

Additional context

A change introduced by PR #87 probably caused this behavior.

Describe the bug

Some projects are not reflecting the cloud provider that is related to.

Expected behavior

Follow a naming convention for our tools, like so "-<language/script>--", like:

• aws-tf-cloud-account-connector == (cloud provider)-(language used)-(name of the project)

Additional steps

Add to the repository more details in the documentation about how the projects should be named.

<PATH_TO_THE_SOLUTION>

Problem to solve

Proposed solution

Alternatives

Additional context

Describe the bug

Add Conventional Commits as a default.

Once a cluster is created only the last one is deleted once cleanup is called.

So, my proposed solution is to tag all cluster which are created by the script.
and then once the cleanup.sh is called, it can either delete the only one cluster if there is only one or it can delete all the tagged clusters.
Or if you find it more clever, it can give the choice to choose which cluster need to be deleted.

• Update the Contribution Guide with secrets that need to be created
• Change the bucket name to be a parameter in the action

Continue the discussion about Add badges to the root README for visibility from PR #13

The idea that "adding badges to the root README will give a wrong sense of code quality for the repo and could send the wrong message and affect confidence and widespread adoption amongst MSPs, partners and community users."

The concern of implementing badges in the root README instead of in each project individually might not reflect the quality of the entire repository, compared to each project individually. For example, if we have 3 vulnerabilities in a single project/code to fix, in case the badges are in the root repository it gives the sense that these are for all projects.