search

Zuehlke / zuehlke.github.io

Zühlke Github Page
http://zuehlke.github.io
10 stars 2 forks source link

Get rid of the duplicated repositories (3 repos for gh-page)! #8

Closed carstenkind closed 8 years ago

carstenkind commented 8 years ago

From @tknerr on January 18, 2016 19:14

We have quite some duplication here (noticed because it immediately confused me when I reported #1):

I just learned that the user / org pages are indeed built from the master branch, and the gh-pages branch was only for project pages: https://help.github.com/articles/user-organization-and-project-pages/

However, we could still:

  1. keep only the https://github.com/Zuehlke/zuehlke.github.io repo
  2. have the sources in there on a source (or similar named) branch
  3. have the generated static site on the master branch
  4. make the source branch the default one in the projetc settings, so users see the proper README
  5. add instructions to the README (i.e. build from source, then push to master to deploy live)

Copied from original issue: Zuehlke/zuehlke.github.io-sources#2

carstenkind commented 8 years ago

From @tknerr on January 18, 2016 20:2

Oh, it's even triplicated, we have this one too:

carstenkind commented 8 years ago

From @kabaehr on January 20, 2016 8:11

Wow triplicated. Well... we (someone who have admin privileges) could definitly delete the org-site repo. If we can change the https://github.com/Zuehlke/zuehlke.github.io repo to be private we could also delete the https://github.com/Zuehlke/zuehlke.github.io-sources repo.

carstenkind commented 8 years ago

From @bruderol on January 20, 2016 12:26

Why should you want to make the github.io page repo private, this is the public site, this won't work probably with github pages.

carstenkind commented 8 years ago

From @bruderol on January 20, 2016 12:33

What @tknerr proposed makes much sense and would also have helped me ... probably I added Scenarioo information now on the wrong repo (master branch on github.io repo, as usual for github.io-organisation-pages).

carstenkind commented 8 years ago

From @bruderol on January 20, 2016 12:54

@carstenkind @kabaehr Can you please give a fast answer: Where should we open issues about the github-io page (for now) and what is the current process (where to change?) the repositories descriptions (e.g. for Scenarioo). I am highly confused.

Also there is even one issue in the repository "core" concerned with this: https://github.com/Zuehlke/core/issues/4

This means we have in total 4 repositories containing something about the zühlke github page ... highly confusing.

carstenkind commented 8 years ago

From @bruderol on January 20, 2016 12:56

For now (unless I get another answer), I assume that the private "zuehlke.github.io-sources" is the correct repo to place issues as feedback to the page.

carstenkind commented 8 years ago

From @kabaehr on January 20, 2016 13:24

Okay, then we will need zuehlke.github.io and zuehlke.github.io-sources because we don´t want to have the unminified ( maybe we should add obfuscation too) files public.

I guess Zuehlke/core is not needed anymore.

carstenkind commented 8 years ago

From @kabaehr on January 20, 2016 13:31

The Answer for the Question on which repo the people should add themselfs or their projects depends on Carsten question: "how should we maintain the people.json and repositories.json". Until then i would suggest a pull-request on the zuehlke.github.io-sources repo

carstenkind commented 8 years ago

From @bruderol on January 20, 2016 13:51

zuehlke/core is still needed: but not for the github page but for other general discussions about the Zühlke open source initiatives (not specific for one repo, admin stuff, etc.)

carstenkind commented 8 years ago

From @bruderol on January 20, 2016 13:53

okay, sorry, I added my descriprions and about Scenarioo now directly to the master branch for zuehlke.github.io - I will add the same also to the sources repo, when finished.

carstenkind commented 8 years ago

From @tknerr on January 20, 2016 15:12

I believe we could still use a single repo for that (just to avoid confusing and duplicated commits across repos) :

  1. Use only zuehlke.github.io
  2. Create a branch named "source" and put the unminified sources there
  3. Make that branch the default branch in the repo settings (i.e. that is the one that is checked out by default when you git clone)
  4. add a build / deploy task to gulp (?) which builds the minified version and commits / maybe even pushes it to "master" (== live)
  5. Run the above build task whenever you want to bring it live

Have not tested it, but it should work that way. I just hate duplucation... ;-) Am 20.01.2016 2:53 nachm. schrieb "Rolf Bruderer" <notifications@github.com

:

okay, sorry, I added my descriprions and about Scenarioo now directly to the master branch for zuehlke.github.io - I will add the same also to the sources repo, when finished.

— Reply to this email directly or view it on GitHub https://github.com/Zuehlke/zuehlke.github.io-sources/issues/2#issuecomment-173210694 .

carstenkind commented 8 years ago

From @tknerr on January 20, 2016 15:37

@kabaehr @bruderol I just removed the org-site repo. One less... :)

carstenkind commented 8 years ago

From @bruderol on January 20, 2016 16:14

One advantage of the second repository: It can be private (not public). I think this is not possible for a branch, is it? And therefore it can contain discussions like this one here, about the content, without everybody seeing it.

carstenkind commented 8 years ago

From @tknerr on January 20, 2016 21:50

yep, agree, the option of keeping certain things private is a plus. And nope, you can't make a branch private, only the whole repo afaik.

We could also have a single zuehlke.github.io repo, but keeping this private. It would still be published if I understand this right:

Note that Pages are always publicly accessible when published, even if their repository is private.

carstenkind commented 8 years ago

From @bruderol on January 21, 2016 10:59

Aha, then it would absolutely make sense to make the repo private (I did not know, that this is possible for pages, very good!).

carstenkind commented 8 years ago

OK, some clarifications here in case you haven't found it yourself.

The single files, which are really duplicates are people.json and repositories.json and maybe some images. They are just copied by the gulp tool chain. And yes, I still don't know how to handle additions and corrections to these files properly.Let'y find it out.

carstenkind commented 8 years ago

BTW. I have missed, that there was a org-site repo.

carstenkind commented 8 years ago

And yes, making the Repo private is interesting. Then we need to change the gulp scripts, so that the top level Index.html is the Release version.

carstenkind commented 8 years ago

From @tknerr on January 22, 2016 16:21

@carstenkind we could still have only a single private repo, but with two branches

Both branches have different structures and can not be merged. Instead, you would checkout the source branch, create a dist build there, and commit that to the master branch (instead of commiting it in the other repo) to bring it live.

Not tested yet, but I believe that should work according to the comments above Am 22.01.2016 11:38 vorm. schrieb "Carsten Kind" notifications@github.com:

And yes, making the Repo private is interesting. Then we need to change the gulp scripts, so that the top level Index.html is the Release version.

— Reply to this email directly or view it on GitHub https://github.com/Zuehlke/zuehlke.github.io-sources/issues/2#issuecomment-173874161 .

carstenkind commented 8 years ago

So we just have to create the source branch in the other repository, and copy the content of this repository to the other repositories source branch, and make that repository private. Correct?

Single concern: The sources are somehow hidden behind the master branch. You have to know the branching strategy, and that you find them in the source branch. But that can be explained in the README.md.

Then we would cleanup this repo and just leave an README explaining that it's dead. We would delete it, when the issues are addressed or has been moved to the other repository. Correct?

carstenkind commented 8 years ago

From @tknerr on January 22, 2016 19:6

@carstenkind yep, that's the idea, plus:

Finally, we could even think of a travis-ci build job that runs the gulp dist build and commits it to master whenever we merge a PR to the source branch. But let's do that in a second step ;-) Am 22.01.2016 6:29 nachm. schrieb "Carsten Kind" notifications@github.com:

So we just have to create the source branch in the other repository, and copy the content of this repository to the other repositories source branch, and make that repository private. Correct?

Single concern: The sources are somehow hidden behind the master branch. You have to know the branching strategy, and that you find them in the source branch. But that can be explained in the README.md.

Then we would cleanup this repo and just leave an README explaining that it's dead. We would delete it, when the issues are addressed or has been moved to the other repository. Correct?

— Reply to this email directly or view it on GitHub https://github.com/Zuehlke/zuehlke.github.io-sources/issues/2#issuecomment-173986002 .

carstenkind commented 8 years ago

@tknerr I did it, please check if it fulfills your expectations. Points still missing

carstenkind commented 8 years ago

From @tknerr on January 24, 2016 20:48

@carstenkind looks all good to me. We still have not pushed anything new to master now that the repo is private, but I'm pretty confident it would work.

We could even test this with a simple dummy change, or just wait for the next real change.

For travis-ci: I created a new issue there, so we can close this one: https://github.com/Zuehlke/zuehlke.github.io/issues/1

carstenkind commented 8 years ago

From @tknerr on January 24, 2016 20:54

Verified that it works even if the zuehlke.github.io repo is private. The <!-- dummy change --> in 1aa1d503c3f327f130c4d6f1d603e92e67f72504 made it live in just a few seconds after I commited it:

image

carstenkind commented 8 years ago

From @tknerr on January 24, 2016 21:1

@carstenkind @bruderol @kabaehr before we close this -- should we move the existing issues to the other repo?

E.g. using this if we are lazy :) https://github.com/google/github-issue-mover

carstenkind commented 8 years ago

After I have moved all Issues, I've deleted the zuehlke.github.io-source repository.

bruderol commented 8 years ago

As discussed and agreed with Carsten I renamed the source branch to develop to be consistent with usual Git Branching Model (see http://nvie.com/posts/a-successful-git-branching-model/).

The leftover source branch can be removed as soon as nobody works on it anymore (??). Use developinstead.

tknerr commented 8 years ago

@bruderol @carstenkind just wondering if the nvie model is really "the usual". In most projects I recommend to use the plain GitHub flow (master + feature branches + release branches), especially if they have a regular release schedule like every 3 months or so. The nvie model obviously fits better in a continuous delivery context where every merge to master goes live (and where you may want to "stage" your changes on a "develop" branch vs. directly releasing every merged feature branch -- which was the intention of that model as far as I understood).

For the zuehlke.github.io site specifically it's a bit tricky, because we don't merge to master and everything that is on the "develop" branch is (the sources of) the live version (on master). I bet you both are aware of that, but it might confuse others which are used to the nvie model and think in terms of "merging to master"...

bruderol commented 8 years ago

@tknerr Maybe I am wrong, but I think, this models are both the same. Also Git flow uses usually the same model with a develop branch. As you can see in this more deeper tutorial about Git Flow (where there is also a 'develop' and a 'master'): http://danielkummer.github.io/git-flow-cheatsheet/

The develop branch is the branch where you integrate all the currently developed feature branches. The master branch only contains what is allready released.

Especially in our case, where the master is not the integrated sources of all potential feature branches (because compiled), you need a different branch than the master (==> develop) to integrate all the features.

But you are right, what might be confusing here, is that the develop branch does not contain the same as the master and is not simply merged to master, because this is generated. I did not consider that. If you think this could cause too much confusion, we could rename it again. (actually it is the master that has the wrong name, but conventions of github-pages for organisation pages forces us to use the master branch for this).

Actually, it does not matter for me. I just renamed it, because Carsten agreed that this is a good idea and told me to go for it (but maybe it was not the optimal solution either, not so sure anymore, sorry).

tknerr commented 8 years ago

@bruderol @carstenkind I'm not fanatic about it, just wanted to highlight the trickiness of master vs. develop in our case, which could potentially confuse someone. So we are aware of it now, and the group of people using that repo is not sooo big anyway. I will leave it up to you whether to keep it or rename it again.

Actually I meant "GitHub Flow" as opposed to "Git Flow" (which is the nvie model afaik too). However, reading it again, the "GitHub Flow" is less of a branching model but more a zoom-in view on how to work with feature branches + pull requests on Github. It talks about branching off from master, but the real essence is about using FBs + PRs, i.e. something that equally applies to the GitFlow model.

bruderol commented 8 years ago

ok, agree, same for me = I will leave it up to you whether to keep it or rename it again. ;-)

Let's just keep it for now, and decide on this, when the CI-build is setup (maybe needs one other integration branch then?). This CI-build might be important, as soon as other Zühlke zheads start to add them to the people/repositories sites, which we should enforce..