A endoflife.date GitHub Action

[sindrel]

Hi! 👋

First of all; thank you for providing such a brilliant service.

I've created a GitHub Action for triggering other actions, like raising notifications, incidents, or issues, based on in-repo data and the endoflife.date API.

When using GitOps patterns or config/infrastructure as code, you can source running versions from in-repo files (e.g., .yaml, .json) to check and track the EoL state of what's live.

Documentation, examples, and code are available here:
https://github.com/marketplace/actions/end-of-life-github-action.

Feel free to leave questions, comments, or feedback!

[captn3m0]

Looks neat. It does feel a bit too complicated to use though.

For notifications, we already have calendar feeds for all our products (with a 30 day notice). Although you can't directly subscribe to the ICS calendar in Slack, you can use a Google or Outlook calendar as a middleware and subscribe directly instead of relying on a GitHub Action.

[sindrel]

Thanks for the feedback! Using calendar feeds is an alternative. But if I understand correctly, that would trigger notifications for all releases/cycles for a given product? And you would have to keep track of which release you are running, manually.

When using the action you only get notified about relevant cycles, sourced from your existing configuration file(s).

For instance, if you're deploying Grafana using Helm/Kustomize and the version is specified in a file like this:

image:
  repository: grafana/grafana
  tag: v11.2.0

And your action is configured like this:

      - uses: sindrel/endoflife-github-action@v1
        name: Grafana
        id: grafana
        with:
          product: 'grafana'
          file_path: 'helm/prod.yaml'
          file_key: 'image.tag'

Then you would only receive notifications about the v11.2 cycle. If bumped to v11.4, then it would start to monitor the v11.4 cycle.

[captn3m0]

The current calendar feed only includes EOL/EOAS events, not the releases themselves. I'm not sure if we include eoes yet, but this is how the Python calendar feed appears in my Thunderbird:

[captn3m0]

Read through the complete comment now. While I can see the advantage of restricting alerts to just a single release cycle - realistically anyone that wants to get notified for Grafana 11.3 will likely not mind getting a notification for EOL for Grafana 11.4 as well..

Users will have multiple Grafana deployments (prod/non-prod/...), and the source of truth for what you're running might differ from what is in a YAML file. I prefer getting notices of all release cycles as a result.

[sindrel]

I get that. Personally, I find great value in my team only getting notified when relevant, avoiding alert/notification fatigue.

When following GitOps principles, what's in the YAML files should be the source of truth, for all deployments. So we (and other adopters) find it's a convenient way to keep track of cycles with very little effort. 👍