Properly sync getfirebug.com with source base from GIT

RESOLVED FIXED

Status

Testing
General
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Honza, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [firebug-p1])

(Reporter)

Description

6 years ago
(cloned from bug 734368)

Some files from Firebug's source base should be regularly copied onto getfirebug.com (mostly testing related files).

Summary:

1) https://github.com/firebug/firebug/tree/master/tests
to:
http://getfirebug.com/tests/

2) https://github.com/firebug/manual-tests
to:
http://getfirebug.com/manual-tests/

3) https://github.com/firebug/test-result-viewer
to:
http://getfirebug.com/test-result-viewer/


Honza

Comment 1

6 years ago
So, I don't know how I can help with this since I have no access to the getfirebug.com site.  It seems to me that this would be easiest by simply having the getfirebug.com site run a cron job that pulls the git repo down a few times a day and copies these directories from the repo into the correct place on the server.

Is it more complicated than that?
(Reporter)

Comment 2

6 years ago
(In reply to Clint Talbert ( :ctalbert ) from comment #1)
> So, I don't know how I can help with this since I have no access to the
> getfirebug.com site.  It seems to me that this would be easiest by simply
> having the getfirebug.com site run a cron job that pulls the git repo down a
> few times a day and copies these directories from the repo into the correct
> place on the server.
> Is it more complicated than that?
No, I think it's simple.

Just the cron job should run every 15 min.

I am CC-ing Michael and Jake. This could be easy to fix no?

Honza
(Reporter)

Comment 3

6 years ago
I am marking as firebug-p1 since Firebug team is really blocked by this.
Could we increase priority of this issue, please?

Honza
Whiteboard: [firebug-p1]

Comment 4

6 years ago
Sorry I missed getting CC'ed on this last month, didn't know there was something blocked on IT.

You just need those 3 git repos (or rather, those 3 dirs within that repo) automatically checked out and deployed regularly? Want to make sure I'm understanding this right. Seems like we can probably just add these as SVN externals to the main repo. Does that seem feasible to you? If so, I think you can just do it and our end should automatically pick up the changes. Github.com supports being added as an external like this (we do it in a few places).


/tests/ is already an svn external pointing to:
tests http://fbug.googlecode.com/svn/tests
This should change to:
tests https://github.com/firebug/firebug/trunk/tests

/manual-tests/ does not exist, so this would be a new external. Something like this:
manual-tests https://github.com/firebug/manual-tests/trunk

/test-result-viewer/ does not exist, so this would be a new external also. Something like this:
test-result-viewer https://github.com/firebug/test-result-viewer/trunk
(Reporter)

Comment 5

6 years ago
Thanks for the info, Jake!

I think that using SVN externals is great idea, this way we can manage the sync configuration ourselves.

One question though, can I create snv:external pointing to a specific branch in GIT?

Honza

Comment 6

6 years ago
I'm pretty sure you can, it just gets tricky as to how exactly the URL should look.

Something like this:

tests https://github.com/firebug/firebug/trunk/tests
or
tests https://github.com/firebug/firebug/branches/<branch-name>/tests

ex:
tests https://github.com/firebug/firebug/branches/dryice-build/tests
(Reporter)

Comment 7

6 years ago
OK, I have setup new svn:externals. The props are set on this dir
https://svn.mozilla.org/projects/getfirebug.com/tests

When updating the repo on my other machine I've got the following error:
UUID mismatch: existing directory 'I:\www\getfirebug.com\tags\production\tests' 
was checked out from a different repository

So, I am unsure if all will just work or there is some manual clean up necessary

Jake, could you please verify?

Thanks!

Honza

Comment 8

6 years ago
I moved the "tests" directory out of the way, to get a fresh pull. Here's what I see:

[root@genericadm.private.phx1 getfirebug.com]# pwd
/data/genericrhel6/src/getfirebug.com
[root@genericadm.private.phx1 getfirebug.com]# svn ^C
[root@genericadm.private.phx1 getfirebug.com]# svn propget svn:externals
tests http://fbug.googlecode.com/svn/tests
swarms https://fbug.googlecode.com/svn/extensions/swarm/branches/swarm1.7/swarms

But in tests/ there are more externals:

[root@genericadm.private.phx1 getfirebug.com]# cd tests
[root@genericadm.private.phx1 tests]# ls
1.9  head  manual  readme.txt  result-viewer
[root@genericadm.private.phx1 tests]# svn propget svn:externals
https://github.com/firebug/test-result-viewer/trunk result-viewer
https://github.com/firebug/manual-tests/trunk manual
https://github.com/firebug/firebug/trunk/tests/content head
https://github.com/firebug/firebug/branches/firebug1.9/tests/content 1.9

An "svn up" in tests works just fine. However, an "svn up" in the main directory does not:

Fetching external item into 'tests':
svn: warning: W155019: Cannot relocate '/data/genericrhel6/src/getfirebug.com/tests' as it is not the root of a working copy; try relocating '/data/genericrhel6/src/getfirebug.com' instead


I suspect perhaps you need to remove the external for "tests" in the main directory? I'm not sure what directory layout you're hoping to have, and where they should all be pulled from.
(Reporter)

Comment 9

6 years ago
Ah, sorry, I forgot to commit the removal of:
 tests http://fbug.googlecode.com/svn/tests
(the old external)

these guys are new:
https://github.com/firebug/test-result-viewer/trunk result-viewer
https://github.com/firebug/manual-tests/trunk manual
https://github.com/firebug/firebug/trunk/tests/content head
https://github.com/firebug/firebug/branches/firebug1.9/tests/content 1.9

and they should be there.

> I suspect perhaps you need to remove the external for "tests" in the main
> directory?
yep, exactly

could you please check it again?

thanks!
Honza
(Reporter)

Comment 10

6 years ago
The new externals doesn't appear online, but it works on my local machine.
Any tips?

Honza
(Reporter)

Comment 11

6 years ago
Jake, could you please help out here?

For example, http://getfirebug.com/tests/manual still doesn't exist

Honza

Comment 12

6 years ago
This is fixed! :)

The copy on our servers was in a weird state where it didn't think /tests/ was under SVN control at all. A simple "svn up" inside of tests did nothing, nor did an "svn up" in the top-level directory... no errors, but nothing pulled down either. I eventually stumbled onto some advice to try "svn up tests" from the top-level directory, and this was sufficient to trigger SVN into pulling that down properly, with all 4 externals. This also made a normal "svn up" start pulling down everything in /tests/ like it's supposed to, including the externals.

Let us know if you have any more trouble with it.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 13

6 years ago
The mapping really seems to work fine now. Thanks Jake!
So creating new externals won't make any problems anymore, I guess?

Sebastian
(Reporter)

Comment 14

6 years ago
(In reply to Jake Maul [:jakem] from comment #12)
> This is fixed! :)
> 
> The copy on our servers was in a weird state where it didn't think /tests/
> was under SVN control at all. A simple "svn up" inside of tests did nothing,
> nor did an "svn up" in the top-level directory... no errors, but nothing
> pulled down either. I eventually stumbled onto some advice to try "svn up
> tests" from the top-level directory, and this was sufficient to trigger SVN
> into pulling that down properly, with all 4 externals. This also made a
> normal "svn up" start pulling down everything in /tests/ like it's supposed
> to, including the externals.
> 
> Let us know if you have any more trouble with it.
Thanks Jake for your help! It works for me now.
Honza

Comment 15

6 years ago
(In reply to Sebastian Zartner from comment #13)
> The mapping really seems to work fine now. Thanks Jake!
> So creating new externals won't make any problems anymore, I guess?
> 
> Sebastian

Right, new externals *should* "just work". :)

(In reply to Jan Honza Odvarko from comment #14)
> Thanks Jake for your help! It works for me now.
> Honza

No problem!
You need to log in before you can comment on or make changes to this bug.