#580 PROPOSAL: move websites repository to pagure
Closed: Fixed None Opened 8 years ago by robyduck.

Infra team and many other projects are moving slowly to pagure and I'd like to see also websites stuff moving there. Pagure has improved a lot recently and actually offers the same (if not even more) functions as fedorahosted. Other features:
pagure supports pull requests, so any contributor can submit fixes, even if he is not in the websites team
pagure also supports filing issues (like github), would be great to have a unique place where to handle the repo '''and''' the trac.
* pagure also has a docs section, we can put our SOPs there and also other documentation

Obviously all the other functions are also there, tagging, webhooks and and and...

I've put a testing repo in https://stg.pagure.io/Fedora_Websites_test if you want to take a look (tell me if you want to be added as committer). [[br]]
Docs for pagure is available here: https://pagure.io/docs/pagure/

My idea would be to start using the pagure repo for the upcoming F24 release cycle, so code and build staging websites there and then move over all the production websites once we release F24 final. That way we will have time to test issues and see how to handle the repo on pagure. Thoughts? Other ideas? Suggestions?


+1 here :) I love it.

+1. I'm planning on moving infrastructure and others there this year as well.

I think it will be a big win for websites to be able to get folks to send PR's...

The infra end should be pretty easy, just switch what git repo we pull from, so I don't see any problems there unless there's a radical change in how the websites are built too.

Should the repo be reorganized to make contributions easier? I decided to take a look at it after noticing #375. It takes a non-trivial amount of time to clone (and the first clone actually failed for me on my fork).

I don't know how many multi-site versus single site updates there are, but it seems that for non-gui driven PRs the cloning may be a serious point of friction.

I believe this could be solved by either having each site in a separate branch or by having each site in a separate repo with a pointer doc in the main repo.

If there is debate on this that resolved this already, I am sorry for not being familiar with it.

Exactly, this is one of the points we want to solve. The repo actually is very big (~800MB), my thought was to archive part of it somewhere else and just keep the last two years. The reason is mainly the static content, such as images etc. Having websites in different branches wouldn't solve the problem, and even making new repos for every single website is not a practical option. We can keep the tree like it is now, making it all much lighter. Thanks for your thougths.

A bit more data.

A clone of my fork fails consistently with this error:

{{{
git clone https://stg.pagure.io/forks/bex/Fedora_Websites_test.git
Cloning into 'Fedora_Websites_test'...
remote: Counting objects: 80535, done.
remote: Compressing objects: 100% (29728/29728), done.
error: RPC failed; result=56, HTTP code = 200 MiB | 482.00 KiB/s
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
}}}

I don't know if this is a problem in my environment, this repo or pagure as I have never tried to clone a pagure fork before.

Also, a clone of the master repo did succeed but took 28m54.509s.

Good point on the branches - I wasn't thinking clearly this morning :)

We are now definitely on pagure. The repo has been cleaned up and we started with just master and f24-alpha branch. Cloning now happens in less than 2 minutes here :)

We will keep the fedorahosted.org git repo for history consultings etc.

https://pagure.io/fedora-websites

Login to comment on this ticket.

Metadata