Idea: automatically generate tarballs for each commit
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
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 (sandbergja@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
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 (sandbergja@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 toevergreen-dev-leave@list.evergreen-ils.org
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 (sandbergja@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-leave@list.evergreen-ils.org
_______________________________________________ Evergreen-dev mailing list -- evergreen-dev@list.evergreen-ils.org To unsubscribe send an email to evergreen-dev-leave@list.evergreen-ils.org
-- Jason Stephenson (he/him) ILS Manager, C/W MARS, Inc. ------------------------------ [image: icon] jstephenson@cwmars.org | [image: icon]www.cwmars.org [image: icon] 508-755-3323 x 418
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 (sandbergja@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-leave@list.evergreen-ils.org
_______________________________________________ Evergreen-dev mailing list -- evergreen-dev@list.evergreen-ils.org To unsubscribe send an email to evergreen-dev-leave@list.evergreen-ils.org
--
Jason Stephenson (he/him) ILS Manager, C/W MARS, Inc.
------------------------------
[image: icon] jstephenson@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-leave@list.evergreen-ils.org
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 ( sandbergja@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-leave@list.evergreen-ils.org
_______________________________________________ Evergreen-dev mailing list -- evergreen-dev@list.evergreen-ils.org To unsubscribe send an email to evergreen-dev-leave@list.evergreen-ils.org
--
Jason Stephenson (he/him) ILS Manager, C/W MARS, Inc.
------------------------------
[image: icon] jstephenson@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-leave@list.evergreen-ils.org
_______________________________________________ Evergreen-dev mailing list -- evergreen-dev@list.evergreen-ils.org To unsubscribe send an email to evergreen-dev-leave@list.evergreen-ils.org
-- -Ken
participants (4)
-
Blake -
Jane Sandberg -
Jason Stephenson -
Ken Cox