You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the code builds ebooks, and then ignores the resulting files completely. Instead, Travis builds ebooks and uploads them as release files on GitHub after any tag. Specifically, in autoupdate_worker, there's this TODO:
# TODO: Make a release out of these once Travis stops doing that for us,# and only if this push event is of a tag.
Implementing that requires the following pieces (and I think only these, but not too sure):
Make Travis stop doing this. I think maybe autoupdate_worker can just delete the travis config files as it works on a repo, and then travis won't try building the release?
Make webhook_server recognize when a tag is being pushed. The information is in the push event, it just needs to pay attention to the ref key in the payload (and possibly some of the other information too).
Make webhook_server include information about the tag in the queue entries. I think adding an attribute to the messages would make sense. Something like tagname=v1.0.0 being present if that's what it is, or just don't put the attribute on messages which aren't tags.
Or maybe it would have better retry behavior if autoupdate_worker just checks if the current master is a tag? Need to think about what happens with retries, and what happens if somebody tags and then pushes another commit to master before the worker gets to it.
The text was updated successfully, but these errors were encountered:
Currently, the code builds ebooks, and then ignores the resulting files completely. Instead, Travis builds ebooks and uploads them as release files on GitHub after any tag. Specifically, in autoupdate_worker, there's this TODO:
Implementing that requires the following pieces (and I think only these, but not too sure):
Make Travis stop doing this. I think maybe autoupdate_worker can just delete the travis config files as it works on a repo, and then travis won't try building the release?
Make webhook_server recognize when a tag is being pushed. The information is in the push event, it just needs to pay attention to the
ref
key in the payload (and possibly some of the other information too).Make webhook_server include information about the tag in the queue entries. I think adding an attribute to the messages would make sense. Something like
tagname=v1.0.0
being present if that's what it is, or just don't put the attribute on messages which aren't tags.Or maybe it would have better retry behavior if autoupdate_worker just checks if the current master is a tag? Need to think about what happens with retries, and what happens if somebody tags and then pushes another commit to master before the worker gets to it.
The text was updated successfully, but these errors were encountered: