Write comments on forks for firehose

[mosuem]

Fixes #156 .

The behavior does change as comments are never deleted anymore; if we want to keep this behavior the TS in .github/workflows/post_summaries.yaml has to be adapted (and we need to store this as an extra parameter passed to the workflow through upload).

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[github-actions]

PR Health

Package publish validation ✔️

Details

Package	Version	Status
package:firehose	0.3.28	ready to publish
package:dart_flutter_team_lints	1.0.0	already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

License Headers ✔️

Details

// Copyright (c) 2023, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

Changelog Entry ✔️

Details

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

Coverage ⚠️

Details

File	Coverage
pkgs/firehose/lib/firehose.dart	💔 Not covered
pkgs/firehose/lib/src/github.dart	💚 12 % ⬆️ 18 %

This check for test coverage is informational (issues shown here will not fail the PR).

This check can be disabled by tagging the PR with skip-coverage-check

[devoncarew]

A few questions:

• I only see one comment on this PR - when using both the health and publish workflows, their output will be combined into one comment? Or is one overwriting the other?
• just confirming that people using this new version of the workflow don't need update their workflow files (ala https://github.com/dart-lang/tools/blob/main/.github/workflows/publish.yaml)
• not being able to update the comment could be problematic. It might be OK for the publish workflow - if we made the normal publish comment super terse - but I could see it being an issue for the health workflow

[mosuem]

• I only see one comment on this PR - when using both the health and publish workflows, their output will be combined into one comment? Or is one overwriting the other?

It took me a while to remember - any changes to the post_summaries.yaml workflow will only be visible when this is merged into the main branch, as this is where the workflow runs.

• just confirming that people using this new version of the workflow don't need update their workflow files (ala https://github.com/dart-lang/tools/blob/main/.github/workflows/publish.yaml)

Yes, as long as they reference @main and not some custom hash it should work directly.

• not being able to update the comment could be problematic. It might be OK for the publish workflow - if we made the normal publish comment super terse - but I could see it being an issue for the health workflow

Updating will still work fine, but there was some logic before to delete the comment on workflow failure for the firehose workflow. I updated the code to also allow this now.

[devoncarew]

Updating will still work fine

Ah, great. I misunderstood - I'd thought this would create new comments on each run.