I have a Cloudflare page that uses python-sphinxto build docs. For some of my commits, it downloads a different version of sphinx than others and fails to build docs correctly.
What I tried:
Adding a dummy commit on top of a failing build seems to fix an issue and force Cloudflare builder to download the correct sphinx version
re-running deployments doesn't fix the issue
creating a new branch with the same head(failing commit) and running another deployment doesn't fix the issue
changing between preview/production deployments has no impact on this issue
Here is a dummy commit I added to make the docs build correctly
Commit one result vs. Commit two result
The diff in deployment logs old commits, the left is Commit 1(not working), and the right, Commit two, correctly builds all three tasks and the releases.
https://www.diffchecker.com/ZpV8vE9D
I have tried making different branches and re-run deployments to check whether the sphinx version will change, but it seems like it's bounded the the "old commit". This is also an issue for other Cloudflare Pages, and using preview/production deployments has no impact on this problem.
The issue in this case was actually not with sphinx version but with the fact that I was using:
git fetch --all
Which does not guarantee pulling the tags with it.
The --all pull from all remotes instead of "everything" as I thought.
Using git fetch --tags instead fixed the issue
Indeed it seems to be a bug, in this case I recommend you to consult directly with CloudFlare support, sometimes they are errors that remain internally in your account and you unbug it, CloudFlare Pages for the moment continues to improve its system, there are details to be corrected.
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 started running GitLab CE inside of an x86 Debian VM locally about two years ago, and last year I decided to migrate the GitLab CE instance to a dedicated Intel NUC server. Everything appeared to go well with no issues, and my GitLab CE instance is up-to-date as of today (running 13.4.2).
I discovered recently though, that some repos that were moved give a "NO REPOSITORY!" error when visiting their project pages, and if they had any issue boards, merge requests, etc, that these were also gone. But you wouldn't suspect it since the broken repos appear in the repo lists along with working repos that I use all the time.
If I had to reason about these broken repos, it would be that they had their last activity over a year ago, with either no pushes ever made to them other than an initial push, or if changes were made, issues created, or merge requests created, it was literally over a year ago.
Some of these broken repos are rather large with a lot of history, whereas others are super tiny (literally just tracking changes to a shell script), so I don't think repo size itself has anything to do with it.
If I run the GitLab diagnostic check sudo gitlab-rake gitlab:check, everything looks good except for "hashed storage":
All projects are in hashed storage? ... no
Try fixing it:
Please migrate all projects to hashed storage
But then running sudo gitlab-rake gitlab:storage:migrate_to_hashed doesn't appear to complete (with something like six failed jobs in the dashboard), and running the "gitlab:check" again still indicates this "hashed storage" problem. I've also tried running sudo gitlab-rake gitlab:git:fsck and sudo gitlab-rake cache:clear but these commands don't seem to make a difference.
Luckily I have the latest versions of all the missing repos on my machine, and in fact, I still have the original VM running GitLab CE 12.8.5 (with slightly out of date copies of the repos.)
So my questions are:
Is it possible to "repair" the broken repos on my current instance? I suspect I could just "re-push" my local copies of these repos back up to my server, but I really don't want to lose any metadata like issues / merge requests and such.
Is there any way to resolve the "not all projects are in hashed storage" issue? (Again the migrate_to_hashed task fails to complete.)
Would I be able to do something like "backup", "inspect / tweak backup", "restore backup" kind of thing to fix the broken repos, or at least the metadata?
Thanks in advance.
Okay, so I think I figured out what happened.
I found this thread on the GitLab User Forums.
Apparently the scenario here is:
Have a GitLab instance that has repos not in "hashed storage"
Backup your repo
Restore your repo (either to the same server or migrating to another server)
Either automatically or manually, attempt to update your repos to "hashed storage"
You'll now find that any repo with a "ci runner" (continuous integration runner) will now be listed as "NO REPOSITORY!" and be completely unavailable, since the "hashed storage" migration process will fail
The fix is to:
Reset runner registration tokens as listed in this article in the GitLab documentation
Re-run the sudo gitlab-rake gitlab:storage:migrate_to_hashed process
Once the background jobs are completed, run sudo gitlab-rake gitlab:check to ensure the output contains the message:
All projects are in hashed storage? ... yes
If successful, the projects that stated "NO REPOSITORY!" should now be fully restored.
A key to know if you need to run this process is if you:
Log in to your GitLab CE instance as an admin
Go to the Admin Area
Look under Monitoring->Background Jobs->Dead
and see a job with the name
hashed_storage:hashed_storage_project_migrate
with the error
OpenSSL::Cipher::CipherError:
TLDR; My version of the SVN-repo differs from my teamates. Even though the repo-UUID is identical and we are using the same branch (exactly the same repo-links).
My SVN was working fine before i went home for vacation.
I came back, updated my repo, commit some changes. Everything seemed to work fine. But it turns out that my team cannot see my commits and when updating - my commit seems to be the latest one. Looking through their clients, the revision-numbers i have checked in collide with other commits.
Im using Ubuntu 18.04.1 LTS -
svn, version 1.9.7 (r1800392)
I tried removing the repository and checking it out (removing the .svn dir as well) - and when i do, my latest commit is HEAD. (Instead of the real HEAD which has a revision number way higher).
When i browse the repo from the web-browser, my commit is HEAD.
When they browse the very same link - their commit is HEAD.
Restarting computer does nothing. Reinstalling subversion (removing ~/.subversion) did nothing.
We tried checking out the repo using different user - still my commit is HEAD.
If i use my account on different machine, it works fine.
The repo-UUID is the same for me and my colleagues.
Im thinking this might be some kind of cache issue, but what cache is both used for svn and browser?
Additional thoughts:
I am also using a VPN to access the corporate network. Could there be a cache there? But the SVN-traffic is using TLS, what could possibly cache TLS-data?
#Simion pointed out that it might be a good idea to make sure the hostname of the Repo resolves in the same IP.
Turns out that was the problem. The CM-Center had moved the repo to another server (and for unknown reasons kept a copy of the repo on the old server - which caused all this confusion) and the Infra department had changed the IP of the repo hostname.
Flusing my local DNS-cache fixed the problem!
Short version: In gitlab how do I view all issues resolved in a commit (or merge request) given that I close issues using git comments (e.g. 'fix #10')?
Long version: In case there is an alternative solution what I'm ultimately trying to accomplish is this. Let's say developer fixes 10 issues, commits, creates merge request and deploys to the staging server. Now QA team needs to know the list of issues that were released so that they can test them. I know this can be done by manually labeling each issue(or assigning a milestone). But since gitlab already knows what issues were resolved in a commit it should be easy to view all issues associated with a commit/merge request. Is it possible to view them?
I have some projects set up on GitLab Cloud, complete with issues, wiki pages, etc. I've recently set up an internally hosted gitlab instance. I'd like to bring these projects over from GitLab Cloud to the internal GitLab instance.
Bringing over the git repos seems easy enough (change the remote and push), but I don't see how to bring over the wikis and issues.
In general it seems like this isn't possible. (There's a GitLab Feedback for it here.)
However, the project wiki's seem to be their own git repos, which you can see on the Git Access tab. While that doesn't solve issues/snippets, it gets you part of the way there.
I don't know how to transfer over issues as I have not had to do that yet, but passing over the wiki is not that difficult.
On your old gitlab instance you will notice two repositories for your project (let's pretend your wiki is oldproject), one will say something like oldproject.git and oldproject.wiki.git.
The general path to the repositories where you can see the names I am talking about (let's assume user-name is "myaccount") can be found here:
/home/git/repositories/myaccount/
or (if using the omnibus installer):
/var/opt/gitlab/git-data/repositories/myaccount/
I presume you already know how to transfer over oldproject.git. You do the exact same thing with the wiki, only you create a bundle file out of oldproject.wiki.git:
git clone http://gitlab-instance-ip/user-name/oldproject.wiki.git
cd oldproject.wiki
git bundle create oldproject-wiki.bundle --all
Now initialize your new project in gitlab...I presume you already know how to do that as you suggested in your question that you know how to import the files from your project over to the new instance without problem. Now repeat for the wiki:
git clone http://new-gitlab-ip/user-name/newproject.wiki.git
cd newproject.wiki
git pull /path/to/oldproject-wiki.bundle
git push -u origin master
I had a very similar problem to yours where I didn't see that anything was actually "pushed". When I went back to the gitlab project I noticed that it was in fact updated with the wiki. See here if you think it will help: Importing Gitlab Wiki to a new Gitlab Instance
Good luck!