Curio::Role::GitLab::API::v4 - Build Curio classes around GitLab::API::v4.
Create your Curio class:
package MyApp::Service::GitLab; use MyApp::Config; use MyApp::Secrets; use Types::Common::String qw( NonEmptySimpleStr ); use Curio role => '::GitLab::API::v4'; use strictures 2; key_argument 'connection_key'; export_function_name 'myapp_gitlab'; always_export; export_resource; has connection_key => ( is => 'ro', isa => NonEmptySimpleStr, required => 1, ); add_key 'anonymous'; add_key 'admin'; default_key 'anonymous'; default_arguments ( api => { url => myapp_config()->{gitlab_api_url}, }, ); sub private_token { my ($self) = @_; return undef if $self->connection_key() eq 'anonymous'; return myapp_secret( 'gitlab-token-' . $self->connection_key(), ); } 1;
Then use your new Curio class elsewhere:
use MyApp::Service::GitLab; my $api = myapp_gitlab('admin');
This role provides all the basics for building a Curio class which wraps around GitLab::API::v4.
Holds the GitLab::API::v4 object.
May be passed as either a hashref of arguments or a pre-created object.
These methods may be declared in your Curio class.
The "access_token" in GitLab::API::v4. See "TOKENS".
The "private_token" in GitLab::API::v4. See "TOKENS".
In your Curio class you may create two methods, "access_token" and "private_token". If either/both of these methods exist and return a defined value then they will be used when constructing the "api" object.
In the "SYNOPSIS" a sample private_token method is shown:
private_token
sub private_token { my ($self) = @_; return undef if $self->connection_key() eq 'anonymous'; return myapp_secret( 'gitlab-token-' . $self->connection_key(), ); }
The myapp_secret call is expected to be the place where you use whatever tool you use to hold your GitLab tokens and likely all passwords and other credentials (secrets) that your application needs.
myapp_secret
Some common tools that people use to manage their secrets are Kubernetes' secrets objects, AWS's Secret Manager, HashiCorp's Vault, or just an inescure configuration file; to name a few.
So, the way you write your token methods is going to be unique to your setup.
This role turns on "does_caching" in Curio::Factory and sets "resource_method_name" in Curio::Factory to api (as in "api").
api
You can of course revert these changes:
does_caching 0; resource_method_name undef;
Please submit bugs and feature requests to the Curio-Role-GitLab-API-v4 GitHub issue tracker:
https://github.com/bluefeet/Curio-Role-GitLab-API-v4/issues
Thanks to ZipRecruiter for encouraging their employees to contribute back to the open source ecosystem. Without their dedication to quality software development this distribution would not exist.
Aran Clary Deltac <bluefeet@gmail.com>
Copyright (C) 2019 Aran Clary Deltac
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.
To install Curio::Role::GitLab::API::v4, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Curio::Role::GitLab::API::v4
CPAN shell
perl -MCPAN -e shell install Curio::Role::GitLab::API::v4
For more information on module installation, please visit the detailed CPAN module installation guide.