Hi all, Thanks for the discussion! I've opened a launchpad and a pullrequest here that builds the tarball when a tag in a format like rel_3_12_5 is pushed: https://bugs.launchpad.net/evergreen/+bug/2115648. Thanks Ken for the autobrr example, that gave some great inspiration.
Looking forward to continued discussion and automation! Thanks, -Jane El mié, 18 jun 2025 a la(s) 9:51 a.m., Ken Cox (kens...@gmail.com) escribió: > 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 < > evergreen-dev@list.evergreen-ils.org> 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 >> (evergreen-dev@list.evergreen-ils.org) 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 < >>> evergreen-dev@list.evergreen-ils.org> 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 ( >>>> sandber...@gmail.com) 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 -- evergreen-dev@list.evergreen-ils.org >>>> To unsubscribe send an email to evergreen-dev-le...@list.evergreen-ils.org >>>> >>>> _______________________________________________ >>>> Evergreen-dev mailing list -- evergreen-dev@list.evergreen-ils.org >>>> To unsubscribe send an email to >>>> evergreen-dev-le...@list.evergreen-ils.org >>>> >>> >>> >>> -- >>> >>> Jason Stephenson (he/him) >>> ILS Manager, C/W MARS, Inc. >>> >>> ------------------------------ >>> >>> [image: icon] jstephen...@cwmars.org | [image: icon]www.cwmars.org >>> >>> [image: icon] 508-755-3323 x 418 >>> _______________________________________________ >>> Evergreen-dev mailing list -- evergreen-dev@list.evergreen-ils.org >>> To unsubscribe send an email to >>> evergreen-dev-le...@list.evergreen-ils.org >>> >> _______________________________________________ >> Evergreen-dev mailing list -- evergreen-dev@list.evergreen-ils.org >> To unsubscribe send an email to >> evergreen-dev-le...@list.evergreen-ils.org >> > > > -- > -Ken >
_______________________________________________ Evergreen-dev mailing list -- evergreen-dev@list.evergreen-ils.org To unsubscribe send an email to evergreen-dev-le...@list.evergreen-ils.org
