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?
Related
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.
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.
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.
I have a public gitlab project here
https://gitlab.com/parmentelat/minisim2
I tried to add a corresponding project in readthedocs.io, so that a new commit being pushed onto gitlab triggers a doc rebuild on readthedocs
I do this routinely with projects hosted at github and it's really easy - at least under my setup - since readthedocs shows me an updated list of github repos right away, and everything goes smoothly after that.
When trying to import this gitlab project under readthedocs though, I have to chose 'Import manually' as my gitlab projects would not show up.
(In the 'connected services' of my readthedocs settings page, I could find a way to connect to github and to bitbucket; gitlab does not seem supported)
Fair enough, I try this manual import, but at that point no matter how I try to spell the project's URL and what method (git or https) I try to use for importing the project, I get this error message
This repository doesn't have a valid webhook set up. That means it won't be rebuilt on commits to the repository.
You can resync your webhook to fix this.
is what I am trying to do doable at all ?
do I need to do something specific on the gitlab side
thanks for any hint
You can manually set the webhook on gitlab.com:
Click the settings icon for your project
Select "Integrations"
Enter the above URL, select "Push events" and "Enable SSL verification"
Click "Add Webhook"
That should do it.
So I decided to switch and start using ssh key to commit my work on GitHub. However, after I created an ssh key and connected it to GitHub when I push it does not show up on my contributions calendar. But it does the push because I can see the changes on the repository on GitHub. Also when I check my settings and under ssh key it tells me that it was used in the past day, but still no commits on the calendar.
After it did not work with ssh key, I tied going back to https link, but now it does not work that way either. I am using the Virtual Box and I am running the Slackware machine on it, where I do all of my development. Only that machine has the problem I described above.
I tried finding the solution, but it seems people did not have this problem as I hoped. Can you explain what's going wrong and how to fix it?
You had pushed with another author's email.
You have a lot of commit and pushed. But when you did these commits some of them were with another email diff than yours at github. So github cant show as yours on the calendar.
Follow these steps to Changing author info history and pushed again to github and the commits will appear on calendar.