Closed dumol closed 3 years ago
Frankly, I would cut all the middle crap and just upload the needed packages to GitHub releases when needed, as I do for python-package
. Not sure I would automate that, for python-package
I write the texts for releases myself to document relevant changes as concise as possible. E.g. https://github.com/chevah/python-package/releases/tag/2.7.18.bd461724
Would it be feasible to use production packages from GitHub releases? This would also help keeping disk usage on Weesp in check, as testing packages are cleaned up regularly.
For the record, using production packages from GitHub releases has been implemented through #19. Publishing production packages is now almost equivalent to publishing a GitHub release.
GitHub releases are few and far between and I prefer to write a relevant summary for all changes since previous release, so I would leave things as they are.
To summarise, when creating a new release, alongside copying locally the needed sub-dir with packages to attach to the GitHub release page, you also have to move that sub-directory from testing/
to production/
on the server publishing https://bin.chevah.com:20443. E.g. on Weesp:
root@weesp:/srv/sftpplus-bin# mv -v testing/3.8.6.e939358/ production/
We can automate by creating a workflow that is triggered when a release is made. The workflow can take the release version from the release name and then automatically execute the mv.
I am ok with the current approach for now.
We can automate by creating a workflow that is triggered when a release is made. The workflow can take the release version from the release name and then automatically execute the mv.
This by itself wouldn't help much, as I get the packages from /testing
on the bin.chevah.com server anyway.
But maybe it's possible to create a draft release and upload corresponding packages when creating a tag? That would help more, but it's no big deal…
@adiroiban dixit:
I think that next would be adding support for production publish .
One option is to trigger a production publish when a tag is created .
Another option is to trigger a production publish via a manual trigger. something similar to our try trigger that we have in brink