cbielstein / aprsweather Goto Github PK

There are several existing methods in the client project that could and probably should be united tested.

• DateTimeExtensions.cs
• DateTimeOffsetExtensions.cs
• PositionExtensions.cs

Potentially more. These don't have tests yet, but they should be added to find any bugs and protect against regressions.

Description

As discovered in #42, the build action workflow is failing from forked repos because forked repos do not have access to secrets, but the doctl setup action requires a token (which is a secret). This causes the whole build workflow to fail.

I've opened digitalocean/action-doctl#67 to propose an enhancement on the action-doctl action to make the token optional for things like this that don't actually require authorization, but in the meantime, we/I should consider workarounds to unblock potential contributors.

Although I could simply remove that validation and rely on the post-merge deployment validation to catch bad changes to the app spec, I think the better option is to break out the app spec validation in to a new file that runs only when the app spec has changed. The result will run validation correctly when this repo has a change on the spec and will only run (and thus only fail) if forked PRs have a change to the app spec. The failure there would at least act as a flag to my review to check the app spec changes and run validation manually.

So the change here would be to move the doctl setup and validation lines from the build job in .github/workflows/build.yml in to a new file such as .github/workflows/validate_app.yml that only triggers on PR with changes to the workflow itself (e.g. .github/workflows/validate_app.yml) or the app spec (.do/app.yml).

For other settings of the action, we can follow similar settings to what's currently in build.yml (ubuntu, etc.)

Acceptance Criteria

• doctl setup and validation code removed from the .github/workflows/build.yml build job
• New .github/workflows/validate_app.yml (or similarly named) workflow created to validate DigitalOcean app spec only when that app spec has changed

Follow something like this: https://docs.microsoft.com/en-us/aspnet/core/web-api/handle-errors?view=aspnetcore-6.0#use-exceptions-to-modify-the-response

Acceptance Criteria:

• Update the tests (marked with TODOs with this issue)
• Ensure 400 errors are returned for argument errors

The DateTimeOffsetExtension.MinutesSince() method is used on the frontend to display how many minutes have passed since a packet was received. Similar logic is run on the backend to double check expiry. Consider either simply moving this extension to the shared project and reusing on the backend or adding it to the WeatherReport<T> class as a method.

The following actions are triggering warnings on node version support ending soon: actions/checkout@v2, actions/setup-dotnet@v1

Update those to higher versions to get away from the warnings.

Currently, the dropdown of example locations will stay on the previous selection, even if a user types in a new value or uses their location.

Instead, when a user types in a location and clicks get weather OR if they use their location, the menu should reset to the hidden placeholder value to avoid confusion.

A stackoverflow discussion seems to imply this is possible using js interop OR potentially with blazor controls like InputSelect.

Description

The pull request template file is currently at path .github/workflows/pull_request_template.md. According to the GitHub documentation it should be directly under .github/.

This is why the pull request template is not being applied.

Acceptance Criteria

• .github/workflows/pull_request_template.md file moves to .github/pull_request_template.md
• After merge, validate that the pull request template is applied when drafting a new PR

AprsWeatherServer logs indicated stopped receiving APRS packets from the server after almost exactly 2 days. This implies a timeout is being enforced.

Code needs to be written to either:

• Periodically re-auth with the server (in case this helps keep alive)
• Retry (or at least fail and restart the container) when connection is lost

The latter needs to be written either way for resilience as timeout isn't the only reason a connection could drop. The former could be nice to prevent docker container restart every few days.

Some investigation needs to be done to see if timeout can even be prevented by periodically sending a response message.

A weather report's "minutes ago" display is only updated when the report is first displayed. This should update each minute to keep an updated display.