4 ms·

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 w

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.

maicro 2y ago
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.
- iamjackg 2y ago
  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.
- inferiorhuman 2y ago
  May as well just implement that in the FUSE driver.
- xg15 2y ago
  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)
- paulddraper 2y ago
  State syncing is always harder than state reading
renewiltord 2y ago
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.
- xuQH9W3HP8 2y ago
  [flagged]
- iamjackg 2y ago
  Yeah, the /dev/disk/by-uuid paradigm was actually the inspiration for adding the second folder!
jrms 2y ago
Why not just 1234-human-sense? You have both type of info there and it's easy to parse too I think.
- iamjackg 2y ago
  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
zufallsheld 2y ago
Any chance of open-sourcing your solution?
dflock 2y ago
There are a bunch of jirafs type things on GitHub, fwiw. Eg. https://github.com/coddingtonbear/jirafs https://github.com/coddingtonbear/jirafs

maicro 2y ago

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.

iamjackg 2y ago
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.
inferiorhuman 2y ago
May as well just implement that in the FUSE driver.
xg15 2y ago
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)
paulddraper 2y ago
State syncing is always harder than state reading

renewiltord 2y ago

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.

xuQH9W3HP8 2y ago
[flagged]
iamjackg 2y ago
Yeah, the /dev/disk/by-uuid paradigm was actually the inspiration for adding the second folder!

jrms 2y ago

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

iamjackg 2y ago
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

zufallsheld 2y ago

Any chance of open-sourcing your solution?

dflock 2y ago

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