Hacker News Reader

Comment by iamjackg | Hacker News Reader

I wish I had known about this a month ago, when I had to go through the exact same process!

In a desperate attempt to find a less frustrating way to interact with Jira, I had the silly idea of starting a jira-as-filesystem project that uses our internal issue categorization to build a tree: directories represent issues, with files representing issue fields and subdirectories for linked issues. I ended up choosing fuse-python.

I haven't worked on it in a minute, but I was already bumping into issues (pun not intended) with the abstraction: using just the issue ID as directory name makes automation easier, but it makes it hard for humans to browse the tree, since a `ls` would just show you a bunch of inscrutable IDs. I ended up adding a parallel `<issue-type>-with-summary` directory type where the slugified summary is appended to each issue ID.

View on HN

Hmm, I'm not saying it's a good idea, but what about a daemon that keeps a symlinked version of the entire jira environment up to date? So you have one jira-as-filesystem that's the raw files, but then for human consumption/interaction, you have a tree of symlinks, including multiple links to the same file wherever it's relevant. Might be adding more layers than needed, based on my lack of understanding, but might technically solve the (current/stated) abstraction issue.

That's sort of what I'm doing behind the scenes, because I keep one global list of downloaded issues (they're lazily loaded when you access them) and then the folders are really only "views" into the downloaded issues. Representing identical ones across trees as symlinks is a fantastic idea though, I can't believe I didn't think of that! Thanks for the inspiration.

May as well just implement that in the FUSE driver.

Would you even need a daemon for that? That sounds as if the FS could just generate the symlinks on-the-fly in the same way that it generates the folders.

(Unless symlinks are somehow special - but at least both /dev and /proc also provide symlinks and to my knowledge they don't have any actual storage behind them, so it should be possible, I think)

State syncing is always harder than state reading

Referencing the same two ways is normal in Unix fs. On a modern Linux you will see disks referenced by block device and UUID. I think your approach is good and consistent with expectations.

Though I, personally, would not use it as JIRA is complicated enough for me.

Yeah, the /dev/disk/by-uuid paradigm was actually the inspiration for adding the second folder!

There are a bunch of jirafs type things on GitHub, fwiw. Eg. https://github.com/coddingtonbear/jirafs

Why not just 1234-human-sense? You have both type of info there and it's easy to parse too I think.

Yeah, sorry, I think I was a bit confusing: that's exactly what I'm doing. For example, an Epic folder is laid out like this:

    EPIC-123
    ├─── user-stories
    │    └─── STORY-234
    └─── user-stories-with-summary
         └─── STORY-234-add-support-for-feature-a

Any chance of open-sourcing your solution?

Reply on news.ycombinator.com