Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Big 3.0 Update 💥 #70

Merged
merged 54 commits into from
Oct 30, 2018
Merged

The Big 3.0 Update 💥 #70

merged 54 commits into from
Oct 30, 2018

Conversation

swissspidy
Copy link
Collaborator

@swissspidy swissspidy commented Oct 24, 2018

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:

  • Uses Traduttore Registry to make the plugin translatable using our own translation platform running Traduttore (inception!). (Use Traduttore Registry in this plugin #73).
    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.
  • Adds source code loaders for Mercurial and Subversion repositories.
    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.
  • Adds support for incoming webhooks from Bitbucket, GitHub, and GitLab (GitLab.com and self-managed)
    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.
  • When scheduling code updates, it first unschedules any existing events.
  • Lots of documentation changes.
    This is far from complete, but is a good start.

Things I still need to do (any help appreciated):

  • Manual Testing
    This includes testing with actual Bitbucket and GitLab repositories.
  • Documentation improvements
    Document and verify steps for repository setup, as well as adding docs for all new filters.
  • Getting the Loader tests to work
    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.
  • Analyze existing class logic
    Might need to move some stuff around. For example delete_local_repository() might make more sense in the Updater instead of Runner.

Fixes #64, #65, #66, #73.

@swissspidy
Copy link
Collaborator Author

The current WIP includes docs for setting up private GitLab repositories.

I think we should try to automate this though, see #57.

@swissspidy
Copy link
Collaborator Author

Made some changes:

When receiving a webhook, the following information about the repository is now stored in project meta:

  • URL
  • VCS type (git, hg, svn, etc.)
  • type (gitlab, github, etc.)
  • visibility (private/public)

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.

@swissspidy
Copy link
Collaborator Author

Linting is failing because PHPCS apparently doesn't pick up @inheritdoc... I guess I have to duplicate all affected docs.

This matches the wording used by GitLab and other sites
We use the `ZipArchive` class which is part of the zip extension.
@swissspidy
Copy link
Collaborator Author

I guess I really need to copy all docblocks. Ugh.

squizlabs/PHP_CodeSniffer#214
squizlabs/PHP_CodeSniffer#1846

@swissspidy swissspidy changed the title [WIP] General webhook handler [WIP] Webhooks, Custom Repositories, Bug Fixes, 💥 Oct 26, 2018
@codecov-io
Copy link

codecov-io commented Oct 27, 2018

Codecov Report

Merging #70 into master will increase coverage by 1.14%.
The diff coverage is 76.64%.

Impacted file tree graph

@@             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) ⬆️
inc/Loader/Subversion.php 0% <0%> (ø) 11 <11> (?)
inc/CLI/UpdateCommand.php 0% <0%> (ø) 6 <0> (+1) ⬆️
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) ⬇️
inc/Updater.php 94.73% <100%> (+0.61%) 22 <2> (+2) ⬆️
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.

Copy link
Contributor

@grappler grappler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally it looks good. I have not tested it yet.

I have added a few comments to the documentation.

docs/bitbucket.md Outdated Show resolved Hide resolved
docs/configuration.md Outdated Show resolved Hide resolved
docs/gitlab.md Outdated Show resolved Hide resolved
docs/gitlab.md Outdated Show resolved Hide resolved
docs/gitlab.md Outdated Show resolved Hide resolved
docs/gitlab.md Outdated Show resolved Hide resolved
docs/bitbucket.md Outdated Show resolved Hide resolved
docs/bitbucket.md Outdated Show resolved Hide resolved
2. Click on "Add webhook".
3. Set `https://<url-to-your-glotpress-site>.com/wp-json/traduttore/v1/incoming-webhook` as the payload URL.
4. Choose `application/json` as the content type.
5. Enter and remember a secret key.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like Bitbucket does not support a secret key in cloud version. https://bitbucket.org/site/master/issues/14683/add-webhook-secret

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still need to test this on Bitbucket to actually write accurate docs. But good to know 👍

@swissspidy swissspidy changed the title [WIP] Webhooks, Custom Repositories, Bug Fixes, 💥 The Big 3.0 Update 💥 Oct 29, 2018
@swissspidy
Copy link
Collaborator Author

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.

@swissspidy swissspidy requested a review from derpaschi October 29, 2018 15:01
Only Bitbucket Server (self-managed) supports webhook secrets
return hash_equals( $token, $payload_signature );
}

return true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks scary having a permission callback which returns true "by default". Can we change this to false by default?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning false by default doesn't work because that means you can't easily use Bitbucket webhooks. Bitbucket.org doesn't support secrets, so 🤷‍♂️

Copy link
Member

@ocean90 ocean90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Once merged, please update our install for some real-world testing.

@swissspidy swissspidy merged commit af7023c into master Oct 30, 2018
@swissspidy swissspidy deleted the webhooks branch October 30, 2018 19:13
@swissspidy swissspidy added this to the 3.0.0 milestone Nov 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants