alt Hacker NewsI 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.
Replies
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.
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.
Any chance of open-sourcing your solution?
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.