Travis configuration issue?
Vangelis66 opened this issue · 4 comments
streamlink's codebase has stayed put on commit streamlink/streamlink@2358e7a
due to issue streamlink/streamlink#310 .
This is well reflected on streamlink's nightly installer S3 repo, on
https://streamlink-builds.s3.amazonaws.com/index.html
where the latest compile is streamlink-0.2.0-428-2358e7a.exe
dated Dec 17th.
However, on the streamlink-portable/nightly S3 repo,
https://s3.amazonaws.com/streamlink-portable/index.html
one can see that travis continues to build what appear to be
identical (all based off commit git-2358e7a) windows zips
even after Dec 17th - e.g. at the time of posting, there exist
seven win32 zips all built off of git-2358e7a; perhaps this is
by design, but isn't it an unjustifiable waste of resources/
storage space on S3 that way?
I don't claim to be an expert on this matter,
but what would be ideal is that travis triggers a new zip if
- Actual streamlink code has changed since the last successful build
or/and - The code of the streamlink-portable script itself has changed
since the last successful build.
Regard this reported issue as an enhancement suggestion,
not as critisism; your constant coding efforts, primarily on
the streamlink repo as well as on this one, are highly
appreciated! 🥇
Happy Holidays 😄
It is by design :-)
They are built once a day (plus once for any script change), this is because it's triggered by a cronjob in travis, and there isn't a super clean way to only build if streamlink has changed. You'd have to store the last commit and only build if it changes, I don't think travis has the ability store variables like that... I could remove the date from the zip file name so that it overwrites any existing one with the same commit, but then you lose the nice ordering in the file names. I have set up S3 to remove builds older than 60 days, so the space it takes on S3 is limited to around 2GB which costs me around $1 per year :-)
It might be possible to setup a webhook from the streamlink repo to build this one on a change.
Also, I plan to add "stable" versions that are built from tags on the streamlink repo :-)
Although, thinking about it now, maybe I can use the date of the last commit for the date... That would be much better. It would still build everyday, but wouldn't keep added zips when nothing changes :-)
Thanks for the idea :-D
Hmm, thinking even more about it, the commit date might not be 100% reliable as there is no guarantee of chronological order in git :-(
I have updated it to use the last commit date, it should be fine as streamlink always merges from pull requests.