## Summary
Actions to add issues to specific projects are failing with the
following:
```Project label assigner action failed with error: Error querying project ID for project number 669: Your token has not been granted the required scopes to execute this query. The 'projectV2' field requires one of the following scopes: ['read:project'], but your token has only been granted the: ['repo', 'workflow', 'write:org'] scopes. Please modify your token's scopes at: https://github.com/settings/tokens. ```
This PR attempts to fix it by removing the offending token and relying on `GITHUB_TOKEN` instead as recommended in [https://github.com/richkuz/projectnext-label-assigner#github-token](https://github.com/richkuz/projectnext-label-assigner#github-token)
## Summary
As we discussed in an email, this is our proposal to facilitating the
Observability teams to create Kibana instances attached to the
Observability test environments by using the GitHub command
`/oblt-deploy`
If an Elastician added a GitHub comment then, the automation will create
the Kibana instance based on the PR changes. Then a comment with the
link to the GitHub issue that contains all the configuration details.
The GitHub issue is not accessible to the public since it's under a
private GitHub repository.
This GitHub action broke, presumably because of changes in the API.
Instead of updating the GraphQL query, switch to use the
project-label-assigner action like the Actionable Observability team
does.
After getting errors on action execution for adding issues labeled with
AO team to the corresponding project, we found out that we were using a
version of projectNext that relies on a deprecated API.
See [projectNext release
notes](/richkuz/projectnext-label-assigner/releases/tag/1.1.0) for
details.
This PR updates the action to use version 1.1.0 of `projectNext`
This enables [GitHub Code Scanning][1] to run on the `main` branch once a day.
The result of the scans can be found under [Security > Code scanning][2].
Running the code scanner takes about two hours, so it's not feasible to
run for every PR, and for now I think it's too much to run on every
pushed commit to `main` as well. However, this can always be enabled
later as needed.
The scan is configured to ignore test files and dev-dependency packages
hosted inside the Kibana repo. If these were included in the scan, it
would take three hours instead of two and the report would include more
noise taking focus away from the important findings affecting
production.
[1]: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning
[2]: https://github.com/elastic/kibana/security/code-scanning
* [Fleet] Update GH Projects automation
Update GH projects automation for issues labeled with `Team:Fleet` to be automatically added to the Ingest Dev project with the proper `Area` property set.
* Update add-to-fleet-project.yml
* Rename add-to-fleet-project.yml to add-fleet-issues-to-ingest-project.yml
* Action to add issue to AO project
* Switch to using richkuz projectnext-assigner as per jasonrhodes suggestion
* Add condition to run only on issues labeled as AO
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Adds workflow for infra monitoring ui team
* Adds other labels for our team
* Updates token to general use one
@tylersmalley mentioned this one exists, so it seems like a safer choice for now. Ultimately we may want a single one from the Elastic org that is enabled for every repo that needs it.
