Tiny Tiny RSS: Community

Versioning changes for trunk

I’m tired of people (this means package and container maintainers, not end-users) who stay on tt-rss tags instead of git master for whatever reason.

Therefore,

  1. Don’t expect any more periodic tags, ever. Prepare to stay in August 2019 forever if you’re using that particularly terrible “linuxserver” container.
  2. Static version prefix is no longer going to be a thing. Your either run off git and get correct timestamp and commit you’re on (because this information is actually useful to help you in case something is broken), or you get “Unknown (unsupported)” because, as far as I’m concerned, that’s what you’re running.

As before, only latest code off git master is supported. If you’re running anything else, update before reporting any issues.

Related: https://community.tt-rss.org/t/version-bump-for-ttrss/2655

Would like to see parsing of .git/HEAD re-added.

At least the git commit that a docker container was built with could be visible.
The most reliable way to consume the tt-rss source via a container is to download the tarball source.
This is usually done by downloading https://git.tt-rss.org/git/tt-rss/archive/${TT_RSS_VERSION}.tar.gz
Then dumping ${TT_RSS_VERSION} into .git/HEAD to display the version.

If you still want it to say unsupported next to it, I think that’s fine.
Perhaps even provide a file which can be parsed that Docker maintainers can dump info into so you’re instantly aware that the user is coming from docker.
Happy to open a PR if this is something you’re willing to consider.

why would you exclude .git when building the container?

what the fuck? it absolutely is not.

you should git pull from your local repository when you need to update or rebuild your container. note how it’s not git clone from scratch, again and again.

also, if you’re downloading tarballs of tags, you’re doing your users a massive disservice by serving them obsolete code for no reason at all.

this is unimaginably stupid. you’re wasting yours and my bandwidth and CPU cycles for absolutely no reason, downloading shit again and again and again and again.

i should 401 all those urls just so people like you would turn on your brains every once in a while. or, even better, hide them behind cloudflare javascript challenge, so normal people wouldn’t be affected by your automated idiocy.

which docker container for tt-rss you’re a maintainer of, so i could publicly shame your horrific efforts? does it also whine for donations on startup like that linuxserver abortion?

e: people like you are basically forcing me to remote-delete all YY.mm based tags from the repository entirely because i can’t beat into your collective heads that those aren’t stable releases.

Look man, I’m just a user of tt-rss and trying to make the linuxserver container better since I’m also a user of that.
I’ve made a few small contributions to both in an attempt to make both work somewhat better together.
No need to be so antagonistic off the bat, not like I haven’t contributed anything to this project.

Anyway, the containers get built via some CI system so it’s not like they have one single build folder that they work out of every time, so yes it would be a git clone every single time.
If the traffic is that bad, maybe I can help set up a mirror or something.
Trying to reduce your headache, not add to it, so I’d appreciate constructive feedback please.

my constructive feedback would be you lurking a bit on this forum and learning at least something about the project you’re half-assedly repackaging (while having the absolute gall to whine for donations to reward your mediocre efforts).

there’s a ttrss-docker thread around here somewhere, i’ve posted some feedback about you doing everything wrong in there some days ago. if you want feedback, you can go and read it, i guess.

this sounds dangerously inept but it’s still going to be an improvement because at least you won’t be serving your users arbitrarily ancient code snapshots.

seriously? it’s not about the traffic per se. it’s about being wasteful and stupid. while also ignoring the underlying development model of this project entirely.

not feeling that, i’m afraid.

Why not use this? That way you get a Fox approved™ container without hassle…

btw my main problem with you is that your container i think is currently first google result for tt-rss docker. and you’re inefficiently serving your users an arbitrary trunk snapshot from six months ago or so. a snapshot which endpoint needs to be manually updated by you.

imagine if there were security vulnerabilities fixed in the last six fucking months?

I asked if you would consider a PR that would allow people that package tt-rss (docker and others) to provide additional version info.
Not sure how that’s a big ask.

Also I’m not a maintainer of any docker container for tt-rss, just a user as I mentioned before.

A container that updates the app source every time it starts up, WCGW?

I have plenty of containers with “latest” as tags. That updates every time it starts and is a good thing™ because I get security releases as soon as I reboot not when some overworked admin decides it’s time to get fix their broken package.

Alternatively, clone it and do a git checkout abv234 or whatnot. It hardly is rocket science.

In addtion, Fox just said:

So you kinda want to stay on that.

They update when you do a docker pull not when the container starts.
The difference is that if the container restarts, the latest tag will start up exactly the same.
The fox container will automatically pull new sources when the container restarts.

Obviously I can build my own Docker container pulling source from git.
This is how I used to do it prior to finding the docker-tt-rss container.
If that’s the only supported way to do it, then so be it.

I’m looking around for this but can’t seem to find it.
I can make some PRs to their repo based on your feedback.

it literally is the first result when searching: https://community.tt-rss.org/search?q=docker :man_facepalming:

tbh since the closure of Google Reader (half 2013), I use ttrss daily, and all the time it failed was my fault …
And since half 2015, i don’t purge any post (actually 136 feeds with 634565 posts).

Unles you run it via Kubernetes which does a docker pull… Whatever. My setup behaves how I want it to: get me the latest, not the latest when some sleepy admin forgot to update it.

Same thing with ttrss… I am running master which is the latest stable release. Everyone else should be doing the same thing. 'nuff said.

what would be the point? the only thing the version is used for in the first place is so that we here could identify where people are standing to help them. it’s useless otherwise.

a container that updates twice a year, maybe, to an unsupported randomly chosen trunk snapshot which may be entirely broken is somehow better?

i’ll concede that it was naive of me to think that people would bother to understand that in tt-rss case tags aren’t stable releases, especially because it goes against the usual pattern. so partly the blame is on me for making new tags and thus adding to the overall confusion.

this was a conscious design choice based on what i wanted to accomplish with it. if you want to update manually, you can easily make a different container.

this doesn’t in any way absolve this linuxserver garbage from doing everything wrong tho.

Ah I never noticed the call for donations in the docker logs…
Obviously this is not a popular feature that anyone wants so I’m just going to go back to building my own containers.

I really do see the point in forcing those who build container-style installations to get rid of the rationale that using tag-based releases for tt-rss makes sense. I never understood Softaculous’ handling of tt-rss, for instance.

That being said, since I’m running tt-rss on a simple hosting provider, which causes git pulls to be impossible to do directly, I used to run this little update script I wrote in order to keep up-to-date. I keep track of all tt-rss commits via RSS, and update regularly when needed, or if I want to post a question here. The script made use of https://git.tt-rss.org/fox/tt-rss/archive/master.zip, and as such, I would really appreciate if you’d reconsider the now disabled .zip (or .tar.gz) downloads of the master branch.

I fully realize that my situation is likely an edge case, though, and that above all you want to make a statement with it.

I’m frankly amazed it took you this long to do this :smiley:

well, main problem was people downloading YY.mm tag tarballs, which are gone now, so i guess there’s no reason to 401 those links anymore. i’ve enabled them back.

i wasn’t really aware how bad it was before i tried that particular docker container. :slight_smile:

Ohhhhhhhh my… annnnnd, 20 characters.

let’s all point at linuxserver dimwits and laugh:

*** IMPORTANT NOTICE ***
THIS IMAGE HAS BEEN DEPRECATED
We are no longer able to ingest tarballs from upstream repo

imagine being so utterly inept (while whining for donations - no i’m not going to let this drop, ever)

e: i guess technically they can enable their shitshow container back because master .tar.gz link is available again, although personally i would prefer them not to.

also: https://github.com/linuxserver/docker-tt-rss/issues/52#issuecomment-562238484 :slight_smile: