Add a scheduled CI job to flag supported platforms going EOL upstream. - #14581
Conversation
By default, it runs at 03:00 UTC every Monday, and checks the upstream EOL date for each platform we support that needs such checking. If the platform will be EOL upstream within the next 30 days, an issue is opened flagging the platform for removal from CI and our support document and auto-assigned to the agent SRE team members. The workflow can also be manually triggered (mostly intended for testing). Data about upstream EOL dates is retrieved from https://endoflife.date via their new public API. Happily, our own definition of what consititutes EOL for our purposes matches up 1:1 with how they categorize platforms as EOL, so the code handling this is relatively simple. The original idea was to open a PR instead with the required changes, but correctly handling the required changes is actually nontrivial to automate, so I decided to just do an issue instead.
|
LGTM! Clean and great implementation! |
|
@thiagoftsm That’s an issue of Codacy not recognizing new syntax that was added in Python 3.10 (see PEP 634 for a formal explanation of the syntax, and PEP 636 for a tutorial). The GHA runners are using Python 3.10, so we can use this syntax without issue in our CI (and I’m strongly in favor of doing so, as it often makes things much easier to read). |
| count=$(gh issue list -R netdata/netdata -s all -S '${{ steps.title.outputs.title }} in:title' --json 'id' -q '. | length') | ||
| if [ "${count}" -ge 1 ]; then | ||
| echo 'exists=true' >> "${GITHUB_OUTPUT}" | ||
| else | ||
| echo 'exists=false' >> "${GITHUB_OUTPUT}" | ||
| fi |
There was a problem hiding this comment.
Will exists be false if gh issue ... fails ([ "${count}" -ge 1 ] fails if count is unset).
There was a problem hiding this comment.
The job will actually fail in that case due to the shell spitting out an error (it ends up trying to compare a string to a number).
This is actually the behavior we want here, because it makes sure we actually see that something went wrong (and it errs on the side of caution by not creating an issue at all in that case).
There was a problem hiding this comment.
Are you sure?
pve-deb-work ~ $ cat -p qq.sh
#!/bin/bash
if [ "${count}" -ge 1 ]; then
echo 'exists=true'
else
echo 'exists=false'
fi
pve-deb-work ~ $ ./qq.sh
./qq.sh: line 3: [: : integer expression expected
exists=false
pve-deb-work ~ $ echo $?
0I did test it in CI and the job doesn't fail.
There was a problem hiding this comment.
Hmm, I was under the impression that script blocks ran with set -e enabled. Apparently not.
There was a problem hiding this comment.
Adding -e doesn't fix the problem (tested in my repo). We could add [ -z "${count}" ] && exit 1.
There was a problem hiding this comment.
Ok, I think I was wrong. The unhandled case: gh exit code is 0 but the command output is not a number. I think we can ignore it.
script blocks ran with set -e enabled
This is correct, but it seems that line 3: [: : integer expression expected in if doesn't stop code execution.
|
@Ferroin merging it (3 2 1 .....) |
Summary
By default, it runs at 03:00 UTC every Monday, and checks the upstream EOL date for each platform we support that needs such checking. If the platform will be EOL upstream within the next 30 days, an issue is opened flagging the platform for removal from CI and our support document and auto-assigned to the agent SRE team members.
The workflow can also be manually triggered (mostly intended for testing).
Data about upstream EOL dates is retrieved from https://endoflife.date via their new public API. Happily, our own definition of what consititutes EOL for our purposes matches up 1:1 with how they categorize platforms as EOL, so the code handling this is relatively simple.
The original idea was to open a PR instead with the required changes, but correctly handling the required changes is actually nontrivial to automate, so I decided to just do an issue instead.
Test Plan
Confirm that actionlint flags no issues with the new workflow.
Beyond that, merge it and see what happens. This is not critical code, it can’t really break anything, and it’s trivial to remove it again if there are significant issues.
Additional Information
Credit to @tkatsoulas for the original idea on this one.