I mistakenly removed default gitlab page (type of user.gitlab.io/project)
How can I restore this?
Thanks you in advance.
Is it possible at all?
Brief Version:
Delete repo, repush and wait.
Detailed Version:
Keep the repo in your local,
Delete repo on gitlab (which will cause losing MR history, but that's not critical for me at least),
Create new Repo (no matter it's same name or not)
Push the code
Then I deleted .gitlab-ci.yml as a commit and added it back as another commit, so that you will see "Congratulations! Your pages are served under: https://username.gitlab.io/project-name" in Gitlab Page Setting, (I am not sure this step is required or not, if I am wrong please correct me, it just automatically worked)
Then you might still get "404 The page you're looking for could not be found." from that link, what you need to do is just WAIT. For me it's about 3 hours (while I am frustrated to looking for other solution, it just worked at some point)
Some explain:
I did step 5 because: it seems gitlab is always automatically enable the default gitlab page once it finds an .gitlab-ci.yml file in your repo.
Related
I changed a badge in one of my company's repos but I messed up the url. Now I can't find the old url. Is there a way I can find the badge's old url?
This is easy in github via git show HEAD~:README.md since badge state and history is stored in the git repo, but I don't see where gitlab stores badge state.
No, there is no history or revert option for badge URLs. The only state is the current state. As soon as you change the badge URL, the old state is lost forever, unless you are self-hosting GitLab and perhaps you have access to logs or database backups...
You will just have to figure out the correct URL somehow. Maybe ask a colleague if they know what the previous URL was.
In the future, it may be good to know that you can preview badges to make sure they are correct.
I've a problem with a Gitlab self-hosted community edition. Recently I've rewrite history on a git repository, and that changed a lot of SHA-1 of commits. I've tried to place the "replace" references, but Gitlab still in Merge Request uses the old commit hashs. After some trials I've tried to export the project and check inside the exported files, and I noticed that Gitlab uses its database to hold the commit hash codes. Is there a safe way to change those commits? I'm the system administrator, so I have full access to gitlab instance and also root access to the machine hosting it.
Thank you all.
In short, no, there's not a way to change this for MRs.
The most you can do is remove the content of the commits from GitLab (the SHA and links will still appear in the MR UI, but they will result in a 404 error after they are removed). This will also remove the ability to see the diffs of these MRs.
To do this, follow the documentation described here for cleaning up repos after history rewrite. After using git filter-repo and uploading the commit map to GitLab, the old commits will be remapped to the new ones (removing all the old references) and the rewritten history will be removed forever.
I've had a success exporting the project, modifying the json file inside the tar gz changing the old commit/new commit, and importing the project.
Yes, now the events are done by the importer (and no more the original committer/pusher), but this is accetable, as the story is now navigable in gitlab with the correct commit as company rules.
in my new project I can't close Gitlab issue's automatically via commit. this is what I try to do:
git add .
git commit -m "close #32"
git push origin develop
in my previous project when I try this codes, issue closed automatically in Gitlab.
what should I do?
First, make sure the commit closing the issue is not the very first commit.
As documented in gitlab-org/gitlab-foss issue 54722, it would not work. By design.
Check if another new commit, with the same comment, works better.
If not, check the GitLab server log for any error mentioning a failure to process the commit comments.
Possibly the feature is disabled from GitLab for certain reason.
Go to GitLab -> Your Project -> Settings -> Repository and see the below screenshot. As seen, the checkbox needs to be enabled in order to avail the auto close functionality based on the reference in the commit message.
I've set up integration between YouTrack and Gitlab, and it is (mostly) working as expected.
We have multiple Youtrack project -> Gitlab Repo mappings configured, with the correct URL for the gitlab server.
When I add a commit hash into the comments, then YouTrack correctly identifies this as a commit hash, and turns it into a clickable link.
However, this link points to https://[youtrackserver]/[reponame]/commit/[commithash] where it should instead be pointing to https://[gitlabserver]/[reponame]/commit/[commithash]. As a result, clicking on it give a 404.
In the past, this has worked (with the commithash URL pointing to the gitlab server), and then ceased to work, and then worked again. I have no idea why, though we have had several upgrades of Youtrack in that time.
We can also set a one-to-many mapping from Youtrack Project to Gitlab Repos. If I do this, then the generate commit hash link URL becomes https://[youtrackserver]/rest/gitHub/checkCommit?issueId=[ticket]&sha=[commithash] . Clicking this simply gives a page with nothing on it but 'NotFound'.
How can I configure this to allow the commithashes to have a working URL?
I have accidentally deleted a Wiki-page from our repository in Azure DevOps.
(How) can I recover it?
That is not an option for us, since we will loose many changes that
were made after the last version no. up until the date I accidentally
deleted the wiki page.
You can choose Clone wiki to download the wiki repo to local machine.
Then use git commands(git revert or what) locally to get the deleted page, once you find the deleted page, publish it and add it back to Wiki page as a new commit.
I was just able to do this without too much fanfare. The resource that was helpful was this VS community topic. There is an answer that provides a solution that doesn't require you to clone the repo.
The key insight is that you can navigate to the Azure DevOps repo UI for the Git repo that's backing the wiki. The solution author says that the shape of the URL is something like https://dev.azure.com/<organization-name>/<project-name>/_git/<wiki-name>.wiki. This didn't quite work for me because we have a different URL scheme in our organization, but I was able to figure it out after a little trial and error. I later saw that you can get the URL by using the Clone Repo UI in the wiki - it gives you the URL, so you can just copy it and navigate to it.
Anyway, the steps were:
Figure out the URL of the git repo that backs the wiki
Navigate to the revision history for the entire wiki
the current UI shows you the Contents tab by default - switch to History
Scroll until you find the commits that deleted the pages you want to restore
it's one of those list views that populate themselves as you scroll, so you won't be able to use the browser page search efficiently, unfortunately
Revert the commits
In my case, this required clicking on them and creating pull requests to revert, but I was able to merge them myself without involving code reviewers. YMMV
All in all, not a wholly terrible experience, but completely undiscoverable.
Assuming you're managing a provisioned wiki (vs using published code as a wiki):
Look in the top-right corner for the vertical 3-dot menu, where there's an option to view revisions:
Choose the revision you want to revert to (e.g. the one prior to deleting the needed wiki page), from the list (click on its version hash):
From the revision details, select "Revert":
At this point, your wiki should be at its prior state, and your wiki page should once again be available.
Note: If you're using published code as a wiki, you would recover/revert your changes as you would with any other code commit.
More details may be found here.
I couldn't find a way to do this through the Azure DevOps web interface but you can restore the page by reverting the commit that deleted it if you clone the wiki locally.
Clone the wiki to your computer - find the clone wiki option in the menu at the top of the left bar which shows the wiki contents, copy the URL and use to clone locally using your usual git client.
Find the commit that deleted the page, the commit message will start with "Deleted page" then the name of the page you deleted.
Restore the page and commit the change. There are various ways to do this - I reverted the commit, you could checkout the commit and copy the page out to make a new commit. You may get a merge conflict on '.order', I'm not sure what the best thing to do is but I kept the current version and haven't had any problems.
Push the changes to Azure DevOps, refresh and you'll see the page has been restored.
This works even for Project Wikis. I wonder if Azure DevOps has added the functionality that enabled this since some of the other answers have been written.