Closed swissspidy closed 6 years ago
The current WIP includes docs for setting up private GitLab repositories.
I think we should try to automate this though, see #57.
Made some changes:
When receiving a webhook, the following information about the repository is now stored in project meta:
This way when trying to clone a repository and update translations, we don't have to check for visibility again (no extra HTTP request), plus we know the repo type even for self-hosted repositories because of the webhook.
Only if no webhook was received you do have to hook into the filters to manually set the repo type or something.
However, with #57 we could mitigate this. Plus with these changes here we'd already have the storage mechanism for such a new settings field.
Linting is failing because PHPCS apparently doesn't pick up @inheritdoc
... I guess I have to duplicate all affected docs.
I guess I really need to copy all docblocks. Ugh.
https://github.com/squizlabs/PHP_CodeSniffer/pull/214 https://github.com/squizlabs/PHP_CodeSniffer/pull/1846
Merging #70 into master will increase coverage by
1.14%
. The diff coverage is76.64%
.
@@ Coverage Diff @@
## master #70 +/- ##
============================================
+ Coverage 67.93% 69.08% +1.14%
- Complexity 189 338 +149
============================================
Files 17 26 +9
Lines 499 828 +329
============================================
+ Hits 339 572 +233
- Misses 160 256 +96
Impacted Files | Coverage Δ | Complexity Δ | |
---|---|---|---|
inc/Loader/Git.php | 0% <0%> (-92.69%) |
7 <0> (-6) |
|
inc/CLI/CacheCommand.php | 0% <0%> (ø) |
5 <5> (+1) |
:arrow_up: |
inc/Loader/Subversion.php | 0% <0%> (ø) |
11 <11> (?) |
|
inc/CLI/UpdateCommand.php | 0% <0%> (ø) |
6 <0> (+1) |
:arrow_up: |
inc/ZipProvider.php | 87.34% <0%> (-7.18%) |
25 <2> (+2) |
|
inc/Loader/Mercurial.php | 0% <0%> (ø) |
7 <7> (?) |
|
inc/WebhookHandlerFactory.php | 100% <100%> (ø) |
5 <5> (?) |
|
inc/LoaderFactory.php | 100% <100%> (ø) |
4 <4> (-1) |
:arrow_down: |
inc/Updater.php | 94.73% <100%> (+0.61%) |
22 <2> (+2) |
:arrow_up: |
inc/Loader/Base.php | 100% <100%> (ø) |
2 <2> (?) |
|
... and 26 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update c0855ad...0ca812a. Read the comment docs.
Updated the description to give a better picture of the changes this involves.
@grappler @ocean90 If you don't mind giving some feedback, any help is appreciated.
I know some people are eagerly waiting for GitLab support, hence the big changes here.
This is a first pass at making Traduttore way more flexible and working for (almost) all sorts of source code repositories.
I got a bit carried away during implementation, so this contains a lot of changes—but I think they're worth it.
Here's a breakdown:
Right now only the plugin meta data and the Slack event names are translatable. In a next step we can extend this to the actual Slack notification messages and perhaps more.
This means Mercurial repositories on Bitbucket can be properly downloaded.
While no Subversion repository provider (e.g. SourceForge) is directly supported right now, the loader could be used by developers with their own repository or developers who prefer using GitHub with Subversion. This can be achieved by hooking into the various filters to override the various class instances.
This is by far the biggest change. It should especially allow using self-managed GitLab repositories without necessarily having to write any custom code to override URLs or things like that.
Upon handling a webhook, repository information like name and URLs are stored as meta data in the database. This means a self-managed GitLab repository will point to the right host and everything after the first incoming webhook.
This is far from complete, but is a good start.
Things I still need to do (any help appreciated):
This includes testing with actual Bitbucket and GitLab repositories.
Document and verify steps for repository setup, as well as adding docs for all new filters.
We don't want to test if Git/Mercurial/Subversion are actually working, but whether the behavior of the classes is correct. Otherwise tests fail if the software isn't installed on your machine (or the CI provider).
I've looked into https://github.com/php-mock/php-mock-phpunit and https://github.com/mikehaertl/php-shellcommand for mocking
exec()
calls and some sort of Command dependency injection.Might need to move some stuff around. For example
delete_local_repository()
might make more sense in theUpdater
instead ofRunner
.Fixes #64, #65, #66, #73.