asyncapi / .github Goto Github PK

Related to asyncapi/community#140
We first identify what is needed to do. Then we will ask TSC if we should proceed

Things to do:

• Organization settings for Repository defaults change to main
  
• First we need to adapt .github repo:
  • change master to main
    
  • update this workflow.
  • we need the following workflows to update to support both, master and main: 1, 2, 3, 4. We cannot just switch to main as these workflows will be automatically updated in all the repositories, where we later need to make changes to default branches.
  • update some markdown files listed here

🆘 Things that I have no idea about are like: is https://github.com/asyncapi/.github/blob/master/git-workflow.md going to work once we change the branch name? some redirect will be created by GitHub?

Please provide more points in the comments and I will update the checklist above. Make it as easy for me as possible in a checklist form, so I just copy/paste 🙏🏼

Describe the bug

If you scroll down to the end of asyncapi/simulator#5 you see that the bot approves the already merged pull requests. Don't think that is intended 🤔

Expected behavior

Did not expect any re-approving of the PR.

Reason/Context

Please try answering few of those questions

• Why we need this improvement?
  Maintainers have to run the workflow everytime manually, whenever new changes are added in PR.
• How will this change help?
  This will save maintainer's time.

Description

Please try answering few of those questions

• What changes have to be introduced?

  • Maintainer can add label named workflow-granted or workflow-run
  • This will trigger workflow runs automatically.
  • So for existing PRs which have new changes, maintainer need not run workflows manually.

• Will this be a breaking change?
  Nope

• How could it be implemented/designed?
  We possibly need to make a github action on this. And do some brainstorming about the real flow, as it includes sensitive data handling.

Action pullreminders/[email protected] work only with event pull_request_review but when hmarr/auto-approve-action@v2 performs approval, the review event is not triggered because in general this is how GH Workflows work, the operations that are performed by them do not trigger events.

So we will never label the PR and therefore we will never autoupdate as we planned here #85

There is no other alternative than I think:

• removing this job https://github.com/asyncapi/.github/blob/master/.github/workflows/automerge.yml#L49
• replace it with custom GraphQL calls or, because it is needed only for autoupdates, we can just use there a simple action just to add a label without checking if PR is approved or not as in the end it doesn't matter. We would only have to make sure it also runs once if: github.actor == ('asyncapi-bot' || github.actor == 'dependabot[bot]' || github.actor == 'dependabot-preview[bot]') && !contains(github.event.pull_request.labels.*.name, 'released') condition is met:

       uses: actions/github-script@v5
       with:
         github-token: ${{ secrets.GH_TOKEN }}
         script: |
           github.rest.issues.addLabels({
             issue_number: context.issue.number,
             owner: context.repo.owner,
             repo: context.repo.repo,
             labels: ['autoapprove']
           }) 

other ideas?

Reason/Context

Lots of projects still use avro specification 1.8.2 for historical reasons and there are no major differences between 1.8.2 schema and 1.9.0 schema.

Description

We just need to add the right mimetypes and consider that in 1.8.2 there is no support for enum default and there is no uuid type.

Describe the bug

automerge.yml workflow will approve PRs that are created by humans but labeled by another bot.

How to Reproduce

See asyncapi/parser-js#472

Expected behavior

automerge.yml should not approve PRs that are created by humans.

Possible solution

in automerge.yml

commands should trigger a workflow only if the comment is created or maybe edited? not if it is deleted.
this issue becomes problematic especially if someone deletes the asyncapi-bot response for /help. It causes all of the commands mentioned in the /help response to run simultaneously.

Describe the bug

The type definition of the Schema class is incomplete, the constructor is not covered.

How to Reproduce

• Check schema implementation
• Check generated types.d.ts

Expected behavior

constructor is covered types.d.ts

TL;DR;

• Node and Npm version should be updated to a more recent one, as we are mostly developing with newer node and npm versions, also because committed lockfiles are version 2.
  Lockfile version 2 is available starting at npm v7, However I think we could update it even to a more recent version.
  For example, Node v16, that includes npm v8).
• npm install command here should be replaced by npm ci so we avoid side effects (no modification of package-lock.json).

Any strong reason to not do this?

Long version if you are not very convinced

The following is a real use case of a bug in the produced image. It took me like an hour to figure out the "bug" (thanks to @magicmatatjahu for pairing!).

The very first Docker image of server-api was built and pushed to Docker Hub by our GH workflow action if-nodejs-release.yml.

Unfortunately, after trying to deploy it to a K8s cluster, we found out that the container was failing due to a missing node module: Error: Cannot find module '@babel/core'. By pulling the same image locally, we discarded the problem was in K8s but in the image itself.
The surprise is that, whenever that image is built locally (e.g. in my computer), the container works like a charm.

But why?

After diving (literally, using dive tool) into both Docker images (the one created by CI and the one created by myself locally), I noticed there was a big difference on a particular Docker layer. In particular, in the one created by COPY package* ./.

As you can see, the package-lock.json filesize differs. The one created by CI is much smaller (554 kB VS 1.2 MB).

After reading both files, I noticed that the package-lock.json from the image created by CI was a version 1 ("lockfileVersion": 1), however both the one created locally and the one available in the repository source code are version 2 ("lockfileVersion": 2).

But how can be possible if dependencies are installed inside docker? See Dockerfile. Could be a bug with Docker? The answer is no.
Dependencies were not built at the time RUN npm ci was executed, by way before. In particular, in the GH workflow action that precedes this. Inside Docker image we only run npm ci, which is intended for just using the pacakge-lock.json as the list of dependencies to install without modification.

This line is running a npm install command, so all dependencies are installed. Is the GH action running an old npm version that doesn't support lockfile version 2? Well, considering that the image where we run is ubuntu-latest, the npm version should be 8.1.2 (according to this). But we are not using that NPM (nor node) executable, but rather the one installed in the previous step, which is:

• Node v14.18.3
• NPM v6.14.15

.

The reason why the npm lockfile version is 1 in CI is because npm install that ran in the workflow with NPM v6.14.15 doesn't understand lockfile version 2 fully, so it literally tries to do the best (which seems it's not the best for us). As the warning says:

❯ npm install
npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!

Due to that missing dependency (@babel/core) that npm couldn't install, the app is broken.

Related issues

• asyncapi/parser-js#427

Reason/Context

• The action that is used there is not yet very well battle-tested and requires updates. For example, now it doesn't work on our org if ts-nats-template is processed. We should just bump https://github.com/derberg/org-projects-dependency-manager in only one global workflow and not in several workflows in different repos
• We can forget to add this workflow when needed, it should just be default. I for example know that it was already forgotten and not added to HTML and Markdown templates and as a result, the Playground doesn't get automated updates

Description

• create here bump.yml file (later it will be updated in other repos where it already resides)

Context

With this issue you create 2 pull requests.

.github repositories are a place for storing community health files for the whole organization, so you do not duplicate CONTRIBUTION guides and others. We choose it as a place for other general files too, like for example https://github.com/asyncapi/.github/blob/master/recognize-contributors.md.

Description

This is what needs to be done:

• Remove this file as it is already here
• Remove this file and create it here in the root of the repository. Add to the newly created document information about:
  • Additional workflows that need to be created in each repository:
    • Release workflow that should be based on this workflow (including tweeting)
    • Automerge workflow that should be based on this. Adjust if statements to check github.actor == 'asyncapi-bot' || github.actor == 'dependabot[bot]' || github.actor == 'dependabot-preview[bot]' instead of github.actor == 'asyncapi-bot'
  • Add this workflow file called sentiment-analysis.yml as somethign that every repo must have:

    name: 'Sentiment Analysis'
    
    on: 
    issue_comment:
        types: 
        - created
        - edited
    issues:
        types:
        - opened
        - edited
    pull_request:
        types:
        - opened
        - edited
    pull_request_review:
        types:
        - submitted
        - edited
    pull_request_review_comment:
        types:
        - created
        - edited
    jobs:
    test:
        name: Checking sentiments
        runs-on: ubuntu-latest
        steps:
        - uses: actions/checkout@v2
        - name: Check sentiment
            uses: derberg/code-of-conduct-sentiment-analysis-github-action@v1
            id: sentiments
            with:
            gcp_key: ${{ secrets.GCP_KEY_SENTIMENT }} 
        - uses: someimportantcompany/github-actions-slack-message@v1
            # this step runs only if sentiment is a negative numner
            if: steps.sentiments.outputs.sentiment < 0
            with:
            webhook-url: ${{ secrets.SLACK_SENTIMENTS }}
            text: Here ${{steps.sentiments.outputs.source}} you can find a potential negative text that requires your attention as the sentiment analysis score is ${{steps.sentiments.outputs.sentiment}}
            color: orange

  • Each repository must be integrated with https://sonarcloud.io/organizations/asyncapi/projects for automated quality and security scans

Reason/Context

All projects from the AsyncAPI Initiative are licensed as Open Source Software, in particular Apache 2.0 license is used by default for new projects.

In an effort to offer high-quality software, not just in terms of code but also in terms of security, transparency, and accessibility, in alignment with our Vision The AsyncAPI community grows 400% stated here we (may) want to adopt the Linux Foundation Core Infrastructure Initiative Best Practices. It also sounds ideal after our announcement made here about AsyncAPI joining a foundation.

Some context:

The Linux Foundation (LF) Core Infrastructure Initiative (CII) Best Practices badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices.
...
The Best Practices Program is an open source secure development maturity model. Projects having a CII badge will showcase the project’s commitment to security.
...
Examples of initial criteria include basic open source development practices (website, open source license, and user engagement), use of change control tools, attention to quality (automated test suite), and focus on security (secure project delivery method, use of dynamic and static analysis tools, as appropriate for the project).

There are different badges for the different criteria levels a project can achieve. Ordered from the most permissive to the most restrictive:

• Passing: focuses on best practices that well-run FLOSS projects typically already follow.
• Silver: is a more stringent set of criteria than passing but is expected to be achievable by small and single-organization projects.
• Gold: is even more stringent than silver and includes criteria that are not achievable by small or single-organization projects.

Description

Even though we may want to achieve the Gold level, Passing and Silver criteria levels should be previously achieved.
That's perfect for splitting this task into smaller actionables so we can adopt each level iteratively.

At least one GH issue should be created per level so we can properly track progress isolated. We can list them right here:

• Passing level issue: TBD
• Silver level issue: TBD
• Gold level issue: TBD

Reason/Context

I do not like, as a user, when I get into some project, I see there was some important issue for the community, but it is either closed or opened forever, but people do not write anything but only share their emojis, thumbs up and others.

The expectation is that maintainers will see that, and frustration arises.

But come one, how could maintainers even see every single issue and all those emotions if you do not approach them directly 🤷🏼

Description

Please try answering few of those questions

• maybe a github action in every repo that calls API on every issue and PR in a given repo and checks emojis
• have some settings like, report only issues and PRs with more than 5 emotions or something like that
• ping us on slack as we do now with new issue or pr, or releases

Quite often automerge fails because like here PR was created, but in the meantime something else was merged and therefore PR was out of sync with master - thus blocked from merging.

https://github.com/asyncapi/.github/blob/master/.github/workflows/automerge.yml workflow needs a step that updates PR to latest master.

We need integrate something like https://github.com/marketplace/actions/auto-update

Reason/Context

We have two workflows for testing, PR testing - if Go project and PR testing - if Node project. they are our most resource-consuming workflows. after merging #129 we will ignore tests for some PRs but I think we can push it further by skipping the workflow entirely if it is not in the appropriate repo.

Description

We can maintain an ignore repo list for each workflow, and skip the workflow early if the current repo is in that list.

Description

Let's create a README for the AsyncAPI organization profile, now that GH rolled out that new feature. It must be visually appealing and we should agree on what is the best to have there. (@derberg thinks one of main things to put there would be all the communication channels.)

Reason/Context

As the Dashboard on the website is being completed, we need a way to automate labelling the good first issues.

Why

By automating the good first issue we achieve two things.

1. It will let us enforce this rule: every good first issue should have complexity and area labels as well.
2. It will make labelling good first issue easier.

How should it work

We should be able to label an issue by commenting these commands:
\good-first-issue javascript easy or \gfi javascript easy these commands should add three labels to the issue( good first issue area/javascript complexity/easy)

Describe the bug

Currently, the GitHub action, checkout the source code (in Windows OS) and defaults to CRLF new line ending, however, if Eslint is restricted to LF it will fail the lint check.

A related issue for more information: actions/checkout#135

We have a couple of options:

• Always force LF

    steps:
      - name: Set git to use LF
        run: |
          git config --global core.autocrlf false
          git config --global core.eol lf

      - uses: actions/checkout@v2

• In the projects where we want to force line endings we have to opt out of the common GitHub action in this repo.

Describe the bug

When adding /rtm on my approved PR, the expected behavior is for GH bot to automatically rebase the branch with the master version. Either way, even though the PR branch was out of date, the PR owner should be able to see a notice of that even when they aren't a codeowner.

Here's the only notice that I saw:

From @derberg:
"we need to think about fix as there are 2 ways to fix it, bot can do update with master or bot can just provide a comment feature like /rtm so anyone can trigger merge….not sure if the first solution will be accepted by all

we do autoupdates already but only in PRs created by bot, as nobody cares about bot’s feelings (this is why robots will kill all humans one day 😄 )

asyncapi/website#526 notice that github bot updated branch with latest master"

Here bot accepted and automerge was triggered asyncapi/spec-json-schemas#104

job log https://github.com/asyncapi/spec-json-schemas/runs/3732367755

Reason/Context

since introducing testing on different platforms it takes now more time to get all CI check ready on PR that can from time to time cause auto-merge action to not merge because of not too many retries

Description

at least double current settings. I checked a few PRs at if automerge works it is usually 9/10 or 10/10 retry

Describe the bug

When the node.js release pipeline bumps the package version often times GH stalls the CI runs, meaning the release pipeline is completely stuck. See asyncapi/modelina#561

Because of the changes introduced in the version bump chore(release): ... we dont need to run all the workflows and in theory skip them.

Reason/Context

Since we are using workflows in our repos a lot and the number of workflows is growing day by day, It is becoming harder to keep track of what workflows are doing and having a big picture of the automation that we do for each repo. for example, what will happen if I open a new issue?

Description

We need a way to document the workflows that we use. I have collected this info about the workflows that we use in the website repo. that table can answer some questions about the workflows but it is definitely not the best possible option.

How could it be implemented/designed?

• First of all, we need a template for the documentation. this table can show what event triggers what actions in general but I think we should document what steps each workflow takes as well. I am not exactly sure, maybe @alequetzalli has some idea on how we can document workflows.
• We will need a library that can be used as a workflow to generate the documentation on workflows just like jsdoc2md does for jsdoc.

• create a dedicated support repo where issues are disabled in favor of discussions
• slack bot should take every message that has this emoji -> called preserve and save in the above-mentioned repo as a discussion
• if the message has a thread, the thread should also be preserved in discussion as part of the main message discussion
• the bot should put a comment under a given thread that the message was saved, where and if possible - who added the emoji to preserve it

Once we have the above, we can think of doing another bot that can pull answers from discussions and suggest them in the message thread on slack. This is long-term though, we need to have a lot of discussions first.

See also: asyncapi/community#26

Reason/Context

• GitHub Actions do not support "global" GitHub Actions (yeap, true).
• We have many workflows that are exactly the same across all repositories. If there is a need to change something in one, we need to go to these 30-something repos and make a change, manually.....omg

Description

Create an action that populates changes automatically for us:

• .github repo is a global repo for us, with global workflows that need to be populated to all other repositories
• we change workflow, like welcome workflow, in .github repo and review it here
• we merge the change and action comes into play
• action picks up that change in workflow was done
  • it clones all repos
  • updates the same workflow file in every repo
  • creates new branch with change and creates pull request
  • automerge workflow in every repo automatically approves and merges PR as it comes from asyncapi-bot
• puppies get crazy of happiness
  Please try answering few of those questions
• What changes have to be introduced?
• Will this be a breaking change?
• How could it be implemented/designed?

Reason/Context

More context here point 4.

We should prepare GH org for a large scale of users with read and not write access. Why?

• cause only a very limited number of users should have write permission
• cause we need to add community members to the organization whenever they are active and help regularly so they can help in issues and PRs triage

So we need a label or comment based system that merges a PR. Label-bases means only org members will be able to add such a ready-to-merge label. Comment-based means anyone can enable merge. Of course, comment based can also be limited to org or team members only (just a matter of additional coding

Description

• discuss and implement 😄

Reason/Context

Internal AsyncAPI dependencies are for example a dependency that Generator has to Parser. So we want to automatically bump version of Parser in package.json for Generator, in Generator repo, once Parser is released.

To have best user experience we should not manually maintain dependency tree between repos and use action only in the repository that runs release

Description

How would it work

• you use this action only in the project that should be updated in other projects
• it is part of release workflow, you just trigger it if there was a change in the version of the package

Configuration Options

• Specify GH token
• Specify where package.json is located in case it is not root
• Specify list of repos that would be ignored and not receive update
• Committer details
• commit message for devDependency, so you can always start it with chore
• commit message for dependency, so you can always start it with fix

• we should also expose on output a kind of information about dependency and it dependents. With another action we can push it somewhere, aggregate it from all the repos and have an application that reads it and builds dependency graph of all repos in the organization

Clicking over the code of conduct link redirects you to a broken URL (see below 👇)

How to Reproduce

Go to the AsyncAPI Initiative profile (here) and click over the code of conduct link

Expected behavior

It should redirect to this link https://github.com/asyncapi/.github/blob/master/CODE_OF_CONDUCT.md instead of this one https://github.com/asyncapi/spec/blob/master/CODE_OF_CONDUCT.md#contributor-covenant-code-of-conduct

Even though we have https://github.com/asyncapi/.github/blob/master/.github/workflows/lint-pr-title.yml, it is not enough. We do validation - great. We put errors in logs - that is nice. Problem is:

• checking logs is not that obvious
• we do not inform clearly what is it all about

I noticed some people are confused. Not everyone reads CONTRIBUTING.md and this is a fact we need to accept 🤷🏼

Would be awesome to have a global GH Actions workflow that, using our bot, posts a message in the PR containing the explanation we already have in the contribu guide -> https://github.com/asyncapi/.github/blob/master/CONTRIBUTING.md#conventional-commits

Here you have an example that publishes a comment in an issue -> https://github.com/asyncapi/shape-up-process/blob/master/.github/workflows/scope-welcome.yml. We need something similar but as a comment under PR, and workflow must react on event pull_request_target

Reason/Context

Same reasons as in asyncapi/parser-js#200 we should disable sentiment-analysis.yml and automerge.yml. It does not make sense to run it whena PR is in draft mode.

Description

Add if: github.event.pull_request.draft == false check and ensure ready_for_review on type are added otherwise when a draft becomes ready to review it wont trigger the job.

Describe the bug

Since the CONTRIBUTING.md file is starting to get referenced in multiple repositories it no longer makes sense that the guidelines are tuned towards the main repository.

Expected behavior

Expected the guidelines to be repository neutral i.e. not include a link to https://github.com/asyncapi/asyncapi/issues/new under opening issues.

I have not screened the entire document, just noticed https://github.com/asyncapi/.github/blob/master/CONTRIBUTING.md#issues

Reason/Context

We have 60 repositories in AsyncAPI organization and it is impossible to stay in sync with settings across all repositories.

We have https://github.com/asyncapi/.github/blob/master/repository-settings.md but it is completely ignored, thus also no longer updated.

Description

We need an application that enables us to manage the settings of the GitHub repository through a config file stored in a given repository.

• Imagine you have a file in a repo that is called .projects.settings.keeper
• it is a yaml file with structure that has info about:
  • discussions: true - that enables discussions tab for project
  • pr: ['squashandmerge'] - that enables only squash and merge on PRs
  • there should be a list of branch protection settings and default workflows that should be blocking PRs
• there also are extra settings like sonarcloud: true or coveralls: true that means the application should make sure sonarcloud or coveralls are enabled for a given project
• basing on CODEOWNERS the app adds given users as maintainers of the repo
• once .projects.settings.keeper is created, global workflow synchronization is triggered to get default workflows into the repo

For GSoC participants

• you will write some JS code
• you will learn GitHub Actions and GitHub API
• you will play a lot with different REST APIs to integrate them together

Reason/Context

With the recent introduction of the CODEOWNERS files, I often have to go and check who are the owners of a repo and then add them to review my PR. It would be awesome to have a slash command that does this for you.

Description

Add a new slash command: /review. This command will trigger a Github action that will read the CODEOWNERS file (if present) and add the listed users as reviewers of a PR.

Bonus

Some people are code owners of just some directories or files in a repo. It would be superb if the action checks the changed files in a repo and add only those affected code owners.

Example: https://github.com/asyncapi/website/blob/master/CODEOWNERS#L11

Alejandra is only a code owner of Markdown files. With this command, she shouldn't be added as a reviewer if no Markdown files have been changed. This will prevent her inbox from being flooded with useless notifications.

We test all npm packages on macos, windows and linux. Macos is the slowest and sometimes npm install fails. Sometimes you don't really want to wait 15min for a PR test to complete.

Hint:

There are some solutions out there that can be plugged into the workflow to cache npm modules or just reuse some other cache.

Describe the bug

At the moment with the CI system, it can occur that we are ended up with a lot of unmerged PRs as such:

How to Reproduce

I have no idea, it happens from time to time 😄

Expected behavior

I would expect the CI system to handle this semi-automatically or give us notice of unmerged PR's as it does in some cases but not all.

Reason/Context

I have been trying to find areas where we can improve our CI/CD pipelines and this seems like the best place to start.

Description

These three workflows (or maybe others) only apply to humans and by skipping these workflows in case the author is one of our trusted bots, we can get more out of GitHub Actions.

We normally want to have it automated but when we do AsyncAPI Specification release then Parser should be released manually with latest JSON Schema and not automatically bumped by the bump workflow

we need some generic solution for this workflow that would not run automated bump because of some specific info. Maybe we can put some specific metadata in chore(release): commits that we can later interpret in the workflow as basically skip that workflow

Describe the bug

Because the workflow does not care about what changes and who did the change, any maintainer can avoid the 1 people review process, by pushing code to the auto-update PRs.

How to Reproduce

Proof: asyncapi/ts-nats-template#413

Expected behavior

The expected behavior would be that the bot does not approve PR's where collaborators have pushed changes to.

Reason/Context

The files CODE_OF_CONDUCT.md, CONTRIBUTING.md, FUNDING.yml, SECURITY.md, and SUPPORT.md should IMO be synchronized to the organization's repositories to provide a coherent documentation experience.

Description

As @derberg suggested on Slack there are two solutions to this.

1. Synchronzie the documents
2. Repository "owners" create their own wrappers to files such as CONTRIBUTING.md and simply reference this repository.

There are pros and cons for both solutions, so what fits best?

I assume it is somewhat related to #38

most up to date description -> #47 (comment)

Reason/Context

Our open governance model introduces a TSC that consists of all the CODEOWNERS that want to use their right to have a vote in TSC decisions making process.

We need a bot/github action that will read VOTERS files from all repos, maintain single list, and put it on the website

Description

• get a github action that reacts on any push to master and checkes if voters file was edited. Then reads it and add/remove/modify a voter in the list stored on the website
• get a github action that on a PR level validates modification in VOTERS file and blocks PR in case VOTERS cannot be added to TSC list as they are affiliated with the company that already reached the limit of representation
• decide on structure of VOTERS file
• get a mechanism that collects more details about TSC members (social accounts, hire availability, etc)

This workflow https://github.com/asyncapi/.github/blob/master/.github/workflows/welcome-first-time-contrib.yml and the first-interaction action that we use it causes headache for the 2nd time

It is failing again on all the workflows, blocking merges and it is closing some serious overload on the GitHub API and therefore rate limit alerts. Not cool at all!

We should remove it (I do not want us to wait for actions/first-interaction#56 and then again in few months face 3rd failure, 2 is enough) and replace with our custom solution:

• we just need to learn from current action how they figure out checking first contributor (now they do a look over all PRs or issues which seems unbelievably harmful for the API -> https://github.com/actions/first-interaction/blob/main/src/main.ts) and do it better, maybe API already allows it, if not rest client, maybe graphql. This workflow is great but not worth it if it is going to cause so many problems in auto merging. We should just push GH for something better, if API is not the answer ATM
• we can have just a custom script like we already do here, and here is some example on how to talk graphql-ish

Recently README.md is published. In this for Spec details; spec latest version is hardcoded.

Reason/Context

Please try answering few of those questions

• Why we need this improvement?
  We have to keep track of this file and change spec version each time of release. We will change things at one website router file if one change is introduced.

• How will this change help?
  Manual spec version change can be avoided.

• What is the motivation?
  Automatically pointing to latest spec release using netlify redirect which is already in use

Description

Please try answering few of those questions

• What changes have to be introduced?
  URL will be changed from https://www.asyncapi.com/docs/specifications/v2.2.0 to https://www.asyncapi.com/docs/specifications/latest

• Will this be a breaking change?
  If we remove the netlify router in website repo it will be changed.

Mentor: @alequetzalli

Context

1. We want to make sure we have healthy community and people respec each other in GitHub. We want to monitor all comments in every repository and analyze sentiments to identify negative ones and get proper notification. Idea is to use GitHub Actions for it, to check sentiments with Google Natural Language API and post negative comments to Slack for review.

2. We manage community files in global .github repo, and we have GitHub Funding config file there too. As a result we need to cleanup all the repos to remove .github/FUNDING.yml

3. Start supporting new GitHub pull request event that allows gives access to GITHUB_TOKEN with write access. Fix welcome contributors workflow is needed.

4. We want to automatically merge Pull Requests that are submitted by Dependanbot. New workflow needs to be added, or if already existins it needs to be modified

Description

1. Add this workflow file called sentiment-analysis.yml to .github/workflows (create it if it doesn't exist yet) directory: https://gist.github.com/derberg/ab362e4b37f542e7e1813e67b7cb11ee
   Proper secrets are already added to GitHub organization so it is as simple as adding above file to workflows dir.
2. Remove .github/FUNDING.yml if it exists
3. If not done already rename pull_request from line 4 to pull_request_target in .github/workflows/welcome-first-time-contrib.yml file
4. Create new file called automerge.yml with the following content: https://gist.github.com/derberg/024814a26959d54f683e7bd68d68f007
   If the repository already has a file called automerge-release-pr-bump.yml than rename it and adjust if statements to check github.actor == 'asyncapi-bot' || github.actor == 'dependabot[bot]' || github.actor == 'dependabot-preview[bot]' instead of github.actor == 'asyncapi-bot'

The workflow stale-issues-prs.yml is referencing action actions/stale using references v1.1.0. However this reference is missing the commit af4072615903a8b031f986d25b1ae3bf45ec44d4 which may contain fix to the some vulnerability.
The vulnerability fix that is missing by actions version could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider to update the reference to the action.

Reason/Context

Now that we have a list of TSC members, I think it's time to create a voting process for TSC members.

Description

We can have a new type of issue called poll on the community repo.

How could it be implemented/designed?

1. having the bot do the following jobs:
   • When a poll issue is created it should notify the TSC members by email or mentioning them on the issue.
   • Notify TSC members that haven't voted before the poll expires.
   • After the poll expires, the bot should count the votes and create a comment announcing the results.
2. having an issue template for polls would be useful since it will make it easier for a bot to read it and do its thing.

How can a TSC member vote?

we can assign emojis to each option and they can vote by reacting to the issue or they can comment their vote.

What about a voting system on the website?

I don't exactly know how that would work. since the website is static and having an authentication system on the website for TSC members only for voting seems a little extra? but it will be fancier though 😃
Would love to know what others think.
cc: @derberg @fmvilas @alequetzalli

I found some broken links in .md files and googled if there are tools to report broken tools and found this github action and this other github action.
It would be nice to have this in all of the repos

Reason/Context

As mentioned here we should start test coverage monitoring.

Description

• setup test coverage, best with some SaaS that is free for open source
• add badges to repos (optional)
• make sure test coverage is a check on a PR level. It is a mandatory check. PR should be blocked from merging if tests coverage decreases with given PR

Describe the bug

Both local golangci-lint binary and the one that runs on CI should be pointing to the same version, which are currently not.

CI script should look to the Makefile in order to see if there is a pinned version and use it, latest otherwise.

Update: 7 Nov 2022

@Samridhi-98 has been working on the design of the app and it looks cool. 👏
You can see the process of developing this app here:
https://github.com/Samridhi-98/github-actions-visualizer
We are trying to see what kind of info is more useful to have there and finalize the design process.

Reason/Context

We are an automation-driven community and we use GitHub Actions to automate lots of things in the organization. GitHub actions aren't unlimited and we need to have a clear picture of what workflows are using what amount of resources and how we can get the most out of GitHub Actions. GitHub currently doesn't provide such a tool to monitor and see the statistics about workflows across the organization.

Description

Basically, we need a web app capable of monitoring and visualizing GitHub actions metrics across the organization by using GitHub API.

Features

• The web app needs to be able to visualize statistics about each workflow across the organization. like, average run-time, the average number of runs per day, etc...
• Besides monitoring each workflow, there should be a graph of some kind so the user can compare workflows together to figure out the most resource-consuming workflows.
• It needs to have some kind of caching implemented into it so It doesn't overload the GitHub API.

Tech stack

• React.js
• you can use Typescript or Javascript.
• D3.js or a library of your choice.

similar projects

I could only find this https://github.com/amirha97/github-actions-stats project which is primitive and visualizes the run-time of actions for one repo.

Reason/Context

Sonarcloud does not create automatically a project on their side whenever we create a GH repository. That means the process is manual and creating them (via https://sonarcloud.io/projects/create) requires ADMIN permission.

Description

Sonarcloud Projects can be created through their UI or rather API as shown here.
That opens the possibility to add some automation around Sonarcloud projects creation through a GH workflow, which will have permissions for doing so.

So far I can see two options for triggering the workflow:

1. Listening to Github Organization Events:
   • Not sure if there is an event dispatched when a new repository is created. If there is, we could just dispatch
2. Manual trigger whenever we create a new repository.