Export GitLab wiki attachment - gitlab

GitLab wiki is a great tool to maintain documentation. It comes with a convenient web interface as well as wiki repository (Git Access) in order to edit the wiki.
Unfortunately, when adding attachments to an article via the web interface, the attachment will not be saved inside of the wiki repository (Git Access). Is there a way to add attachment to wiki without using the Git Access?

To put it bluntly, no there isn't. (At least not yet, as of version 8.9) Files which are uploaded as Attachment are being put in a uploads/ folder which is global.

Related

Where can I manage files uploaded to wiki of a Gitlab.com project?

I have uploaded some files to my Gitlab repository on "gitlab.com" while creating wiki for my private project.
Now my questions are:
Can I see list of the uploaded files?
Is there any way to remove some of them?
Why permission of uploaded file is public? Can I change it to private?
Current version of gitlab is Enterprise Edition 8.9.4-ee.
Attached files trough the wiki editor are uploaded to /uploads/. As of GitLab version 8.9.0 you are unable to manage these files (i.e. deleting them).
If you want to manage attached files yourself you can clone the wiki as repository. You can find the clone URL in Wiki -> Git Access. It should look something like this: git#<link to gitlab>:<group/user name>/<project name>.wiki.git. In the cloned repository you'll not find the /uploads/ directory, because it is located outside of the repository. Bun there you can put your images or other attachments, and link them within your wiki. The link to the image is relative to the repo root so if your image image.png is in the root folder you can link it with markdown like this![Image title](image.png).
Permission wise these files will only be visible to Users which have at least Guest access to your project, even if they have a direct link.
Wikis are based on Git repositories, so you can clone them locally and edit them like you would do
Actually... See GitLab 14.0 (June 2021)
Edit wiki pages with the WYSIWYG Markdown editor
Edit wiki pages with the WYSIWYG Markdown editor
Editing wiki content could be so much easier! Many GitLab wikis use Markdown formatting, and for some users, Markdown is a barrier to efficient collaboration. In this release, you now have access to a rich, modern Markdown editing experience in your wiki, so you can edit with confidence.
Instant feedback and visual editing tools help make wiki editing more intuitive, and remove barriers to collaboration. GitLab saves the changes as Markdown when you’re done, so users who want to edit the Markdown directly can do so. You can even type Markdown into the new editor and it will automatically format the text as you type.
GitLab 14.0 introduces the Content Editor into the Wiki with support for most of the basic Markdown content types like headers, bold and italic text, lists, code blocks, and links. Full support for the entire GitLab Flavored Markdown specification will arrive in upcoming releases. We also plan to make the Content Editor available in other areas of GitLab in the future. We welcome input on this early MVC in this feedback issue.
See Documentation and Epic.
And yes, that include page deletion.
Alternatively:
See GitLab 14.2 (August 2021)
Upload and attach files in the new wiki editor
GitLab 14.1 introduced the ability to upload and insert images into the new wiki content editor.
Now in GitLab 14.2, you can upload and attach .zip, .pdf, .txt, and other binary files in the same way.
This brings us one step closer to feature parity with the classic wiki editor, and unlocks additional ways for you to collaborate on rich content in your wiki pages.
See Documentation and Issue.
See GitLab 14.9 (March 2022)
Render pasted Markdown in the wiki WYSIWYG editor
Markdown content destined for your GitLab wiki is sometimes created outside of GitLab.
In the “classic” wiki editor, you can paste valid Markdown with no problem, because you are working with the raw source. The page only renders when you submit the content.
In the wiki WYSIWYG editor, however, your clipboard’s content might have been pasted in as plain text, forcing you to manually reformat every line to remove Markdown syntax and re-format it using the WYSIWYG tools.
In GitLab 14.9, the Markdown content you paste into the WYSIWYG editor using Command / Control + V is parsed and rendered as rich text.
You can still force the content to paste as plain text using Command / Control + Shift + V.
See Documentation and Issue.
See also GitLab 15.5 (October 2022):
Autocomplete suggestions in the Content Editor
GitLab Flavored Markdown provides convenient shortcuts for referencing GitLab-specific items like users, issues, epics, and even emojis in your content. For example, you can type #35266 to link to that issue or :thumb to see a list of thumb emojis. Now when you use the Content Editor, you get access to the same powerful autocomplete suggestions.
See Documentation and Issue.
For GitLab versions 11.3 and later, any files attached to wiki pages can be found and altered by cloning the wiki repository (from link on the right sidebar) and navigating to the /uploads folder inside the local repo. Changes can be pushed up.
Where files are stored
Attach a file, and GitLab stores it according to your installed version of GitLab:
Files added in GitLab 11.3 and later: Files are stored in the wiki’s Git repository.
Files added GitLab 11.2 and earlier: Files are stored in GitLab itself. To add the file to the wiki’s Git repository, you must re-upload the file.
GitLab - Create a new wiki page
How to get a local repo of the wiki
Wikis are based on Git repositories, so you can clone them locally and edit them like you would do with every other Git repository. To clone a wiki repository locally, select Clone repository from the right-hand sidebar of any wiki page, and follow the on-screen instructions.
GitLab - Create or edit wiki pages locally
Restricting users that can view wiki pages
It is not currently possible to restricting what pages users/groups can see on GitLab wiki. There is a GitLab issue that recommends this feature. This extends to files in the wiki repo.

Is there a way to integrate gitbook and sharepoint cleanly?

I have several books in Gitbook and am bouncing users from the Sharepoint based intranet to documentation in Gitbook. Is there a way to automatically embed the Gitbook content into Sharepoint so it looks like it is integrated within the intranet?
I have successfully integrated Gitbook into Sharepoint. Initially I tried the answer provided above, but that rendered my gitbook inside a window within Sharepoint which looked bad to me.
Here is the way I accomplished it:
Using the Gitbook CLI Toolchain installed on a linux computer, issue the gitbook build command.
Take the output from this command, which is a folder called _book, and upload its contents to your Sharepoint documents folder.
Take care to replicate the folder structure exactly. This is a bit tedious since Sharepoint doesn't allow you to upload folders (at least not my instance).
Rename every .html document in the _book folder to .aspx. This allows Users to visit a page when they click a link rather than downloading the page. If i'm not mistaken, I also had to edit the links to my books pages inside the index.aspx page from .html to .aspx as well.
Here comes the cool part... visit the link provided for the (now) index.aspx. Get the link by clicking the ... button next to the file in Sharepoint. And...bingo, Sharepoint will serve your entire gitbook as a static site.
Hope this helps

GitLab: How to display Wiki as start page instead of readme?

I want to have the start page of the wiki of a project in GitLab as general start page for the project. Is this possible?
This isn't currently possible. The only views available which you can find in /profile/preferences are activity and readme.
This is possible because there's a bug in gitlab does exactly what you want, but only
for logged in users accessing
a public wiki-only project
So i guess „It's not a bug, it's a feature" ;)
Update
Having checked the example repository in the above linked issue, what you're asking for seems to be the default behaviour on gitlab.com now for wiki-only projects (which means you have to go into the settings and disable the repository feature).
I just verified that by setting up a fresh wiki-only project and it shows empty wiki page as homepage which was introduced in 12.5.

Document Mng on Redmine: Anyone use DMSF plugin or find an easy way to manage docs in the Files tab with a 'wiki' as a front end?

I'm looking to use Redmine for document management. I know that Redmine is not ideal for this task but there is already a lot of content on the site so I'd like to utilize it if possible.
Redmine currently does not a have great documents module. The files we've uploaded look to be amended on that specific page and it doesn't seem to be able to move to another page (unless you download and re-upload to the proper page).
Idea 1
I see there is a Files section, which could work as a central repository (and you can upload document based on release) however, is there a way to set up a nice-looking 'front-end' page that automatically updates based on new submissions to the Files tab? I envision this front end to be a simple wiki page with the document name, a short description and a links to the file posted in the Files tab.
There are so many documents uploaded to varying pages on the Redmine site. I would only do the whole download and re-upload of files if there was a way to automatically update the 'front end' wiki.
Idea 2
I see there is a DMSF plugin for Redmine. Has anyone used this before and has is solved document management issues? I'd like to hear your feedback. Even if DMSF doesn't totally solve my issue, anything is better than what I have now.
Thanks!
In my opinion DMSF module is a perfect companion for Redmine. We have adopted it in our company. You can easily deal with document versions, webdav access, custom approval workflow, document modifications notification with the extra value of being well integrated with Redmine features (roles, dynamic links in Wiki and issue text and notes).

Jekyll/Poet blog - remote path for markdown files?

I am going to deploy my blog, which is based on Poet (blog generator in node.js), but I am wondering if it's possible to specify remote path for my markdown files. It's similar to Jekyll where you specify the _posts directory, it will then read all markdown files in that folder and include them in your blog.
Why would I need a remote directory? Because I don't want to do this every single time:
git add _posts/06-24-2013-new-post.markdown
git commit -m 'added new blog post'
git push
I simply want to drag and drop my markdown file into my Dropbox or Amazon S3 and have Poet automatically read those files.
Surely people have done something like that before?
Here is the Poet's config object. Can I change posts to point to me.s3.amazonaws.com/_posts/ or my Public Dropbox folder?
poet.set({
posts: './_posts/', // where all .markdown files are stored
postsPerPage: 5,
metaFormat: 'json'
});
we are using stackedit (and publishing to the local dir via ssh), but poet has a fault: check issues #15 and #27.
we are using these blog engine (here) cause these.
StackEdit Github Repo
Demo
Some Features:
StackEdit can:
Manage multiple Markdown documents online or offline
Export your documents in Markdown or HTML and format it using a template
Synchronize your Markdown documents in the Cloud
Edit existing Markdown documents from Google Drive, Dropbox and your local hard drive
Post your Markdown document on Blogger/Blogspot, WordPress, Tumblr
Publish your Markdown document on GitHub, Gist, Google Drive, Dropbox or any SSH server
Share a link to a Markdown document that renders it in a nice viewer
Show statistics about your document
Convert HTML to Markdown
Features:
Real-time HTML preview with Scroll Link feature to bind editor and preview scrollbars
Markdown Extra support and Prettify syntax highlighting
LaTeX mathematical expressions using MathJax
WYSIWYG control buttons
Configurable layout
Theming support with multiple themes available
A la carte extensions
Offline editing
Online synchronization using Google Drive and Dropbox
One click publish on Blogger, Dropbox, Gist, GitHub, Google Drive, SSH server, Tumblr, WordPress

Resources