Love the bold ideas here, and don't let the perfect be the enemy of the good. Quite a lot of automation is possible incrementally. I have borrowed from the Autobrr release workflow <https://github.com/autobrr/autobrr/blob/develop/.github/workflows/release.yml> ; it uses tag pushes to automatically build release artifacts and a Changelog <https://github.com/autobrr/autobrr/releases/tag/v1.63.0>. Only problem I had with that workflow was when I pushed the tag without pushing the commit, but that is easily fixed.
Ken On Wed, Jun 18, 2025 at 11:01 AM Jane Sandberg via Evergreen-dev < [email protected]> wrote: > I like the idea of building tarballs when a tag is pushed! The github > integration with POEditor would be great. In the meantime, one idea > to handle translations automatically would be to create an ssh keypair for > github actions to use to push translation commits to our own git server. > > El mié, 18 jun 2025 a la(s) 6:25 a.m., Jason Stephenson via Evergreen-dev ( > [email protected]) escribió: > >> Jane & Blake, >> >> I don't know if we really want tarballs for every commit. That seems like >> a lot of artifacts hanging around. If we could get github to build tarballs >> when a tag is created, that might be more useful in my humble opinion. >> >> As for automating the whole release process, if we could get the github >> integration working with POEditor, then I think that takes care of the >> translations. We could move the LP translations to POEditor and be done >> with messing with translation exports and imports, etc. >> >> At that point, we could have github build the release tarballs, I think. >> >> Once we're doing that we could transition to github and shut down our own >> git server. >> >> Just some thoughts before I build a release. >> >> Jason Stephenson >> >> On Tue, Jun 17, 2025 at 7:07 PM Blake via Evergreen-dev < >> [email protected]> wrote: >> >>> Jane, >>> >>> I'm all for it! I must have missed your previous post. It's the >>> POEditor, LP translations and release notes pieces that seem to evade >>> automation. Did you have something in mind for those or maybe for the >>> purposes of this github automation we don't need* those things? >>> >>> -Blake- >>> Conducting Magic >>> Will consume any data format >>> MOBIUS >>> >>> >>> On 6/17/25 5:44 PM, Jane Sandberg via Evergreen-dev wrote: >>> >>> Hi all, >>> >>> Any feedback on this? I'm building a release right now, and honestly >>> I'm feeling quite burnt out about all the time-consuming and error-prone >>> manual steps involved -- which are almost the exact same time-consuming and >>> error-prone manual steps we've had for quite some time. >>> >>> I'd be very willing to put substantial effort towards the steps I >>> proposed above. If you have a different idea for how to approach the >>> automation, please let me know and I'd be very happy to help with >>> a different approach. But I can't support the status quo: it uses far more >>> of our community's precious time than it should, and it's far too easy to >>> make a small mistake and create a bad release, and I've had enough of that. >>> >>> Thanks for your consideration, >>> >>> -Jane >>> >>> El jue, 3 abr 2025 a la(s) 8:00 a.m., Jane Sandberg ( >>> [email protected]) escribió: >>> >>>> Hi Evergreeners, >>>> >>>> Throwing out a release process idea for your feedback: what if we had >>>> github actions build tarballs on each commit (using make_release in >>>> build-only mode)? >>>> >>>> In my imagination: the release process would be much the same as it is >>>> today until the make_release step. The builder would generate the upgrade >>>> script and bump version numbers as they do today, then push those changes. >>>> This push would trigger github actions to build the tarball, so the builder >>>> wouldn't have to. >>>> >>>> As I see it: >>>> * this would free us up from any issues and inconsistencies in the >>>> tarballs that result from folks' different environments and/or unclear >>>> instructions. >>>> * folks could test the newest code from a tarball at any time >>>> * if you catch a mistake after you're done building, you could simply >>>> push the correction and wait for the robot to generate an adjusted tarball, >>>> rather than needing to spin up your environment again or coordinate with >>>> somebody else. >>>> * since make_release would be running *all* the time, we would be able >>>> to catch errors we introduce to that script early >>>> * this would be an incremental step towards yet more automation of the >>>> build/release process >>>> >>>> I believe we'd need to expire those tarballs after a certain amount of >>>> time so we don't hit github storage limits. >>>> >>>> What do you think? >>>> >>>> Thanks, >>>> >>>> -Jane >>>> >>> >>> _______________________________________________ >>> Evergreen-dev mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> _______________________________________________ >>> Evergreen-dev mailing list -- [email protected] >>> To unsubscribe send an email to >>> [email protected] >>> >> >> >> -- >> >> Jason Stephenson (he/him) >> ILS Manager, C/W MARS, Inc. >> >> ------------------------------ >> >> [image: icon] [email protected] | [image: icon]www.cwmars.org >> >> [image: icon] 508-755-3323 x 418 >> _______________________________________________ >> Evergreen-dev mailing list -- [email protected] >> To unsubscribe send an email to >> [email protected] >> > _______________________________________________ > Evergreen-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- -Ken
_______________________________________________ Evergreen-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
