@jsbarretto it's sort of the opposite for me. My "great benefits to society have probably been OSS contributions, but definitely stuff I only did because of the day job. Contributing to csv libraries, logging libraries, documenting something in #appveyor that the author didn't know, Microsoft documentation, etc. And a few stackoverflow questions and answers.

More people have been impacted by all that than all the things I did for fortune 500 companies

Just migrated 40-ish git repos to use #GithubActions for testing on Windows instead of #Appveyor. Each push will have triggered 20-ish builds. Oops. And on 50-ish repos I had to tweak the MacOS build. Again, each push will have triggered 20-ish builds. And now my builds are being rate-limited. Outrageous! I demand a refund!

From release to support

2019: #Python 3.8

🥇 21 hours: #TravisCI
🥈 20 days: #GitHubActions
🥉 24 days: #AzurePipelines
4️⃣ 25 days: #AppVeyor

2020: Python 3.9

🥇 17 hours: GitHub Actions ⬆️
🥈 20 days: Travis CI ⬇️
🥉 21 days: AppVeyor ⬆️
4️⃣ 22 days: Azure Pipelines ⬇️

2021: Python 3.10

🥇 12 hours: GitHub Actions ↔️
🥈 17 days: Azure Pipelines ⬆️
🥉 28 days: AppVeyor ↔️
4️⃣ 106 days: Travis ⬇️

2022: Python 3.11

🥇 a day: GitHub Actions ↔️
🥈 2 days: Azure Pipelines ↔️
🥉 14 days: AppVeyor ↔️
4️⃣ 28 days: Travis ↔️

#TIL when you contribute to a project that use #Appveyor CI to test build on #Windows, the system sometimes build the code you have just pushed, but often a previous version of the code (in spite of what the commit hash say).

It can therefore be convenient to output canaries in the build script so that you can ensure success / failures are related to the last version of the code (by checking them visually in the log).

When it does not match:
git commit --amend
git push -f