licensed 2.15.2 → 3.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/.github/workflows/test.yml +55 -11
- data/CHANGELOG.md +56 -1
- data/README.md +38 -81
- data/docs/adding_a_new_source.md +11 -8
- data/docs/commands/README.md +59 -0
- data/docs/commands/cache.md +35 -0
- data/docs/commands/env.md +10 -0
- data/docs/commands/list.md +23 -0
- data/docs/commands/migrate.md +10 -0
- data/docs/commands/notices.md +12 -0
- data/docs/commands/status.md +73 -0
- data/docs/commands/version.md +3 -0
- data/docs/configuration.md +9 -161
- data/docs/configuration/README.md +11 -0
- data/docs/configuration/allowed_licenses.md +17 -0
- data/docs/configuration/application_name.md +63 -0
- data/docs/configuration/application_source.md +64 -0
- data/docs/configuration/configuration_root.md +27 -0
- data/docs/configuration/configuring_multiple_apps.md +58 -0
- data/docs/configuration/dependency_source_enumerators.md +28 -0
- data/docs/configuration/ignoring_dependencies.md +19 -0
- data/docs/configuration/metadata_cache.md +106 -0
- data/docs/configuration/reviewing_dependencies.md +18 -0
- data/docs/{migrating_to_newer_versions.md → migrations/v2.md} +1 -1
- data/docs/migrations/v3.md +109 -0
- data/docs/sources/bundler.md +1 -11
- data/docs/sources/swift.md +4 -0
- data/lib/licensed.rb +1 -0
- data/lib/licensed/cli.rb +6 -3
- data/lib/licensed/commands/cache.rb +19 -20
- data/lib/licensed/commands/command.rb +104 -72
- data/lib/licensed/commands/environment.rb +12 -11
- data/lib/licensed/commands/list.rb +0 -19
- data/lib/licensed/commands/notices.rb +0 -19
- data/lib/licensed/commands/status.rb +13 -15
- data/lib/licensed/configuration.rb +105 -12
- data/lib/licensed/report.rb +44 -0
- data/lib/licensed/reporters/cache_reporter.rb +48 -64
- data/lib/licensed/reporters/json_reporter.rb +19 -21
- data/lib/licensed/reporters/list_reporter.rb +45 -58
- data/lib/licensed/reporters/notices_reporter.rb +33 -46
- data/lib/licensed/reporters/reporter.rb +37 -104
- data/lib/licensed/reporters/status_reporter.rb +58 -56
- data/lib/licensed/reporters/yaml_reporter.rb +19 -21
- data/lib/licensed/sources.rb +1 -0
- data/lib/licensed/sources/bundler.rb +36 -217
- data/lib/licensed/sources/bundler/missing_specification.rb +54 -0
- data/lib/licensed/sources/go.rb +1 -1
- data/lib/licensed/sources/gradle.rb +2 -2
- data/lib/licensed/sources/npm.rb +4 -3
- data/lib/licensed/sources/nuget.rb +57 -27
- data/lib/licensed/sources/swift.rb +69 -0
- data/lib/licensed/version.rb +1 -1
- data/script/source-setup/go +1 -1
- data/script/source-setup/swift +22 -0
- metadata +27 -4
- data/docs/commands.md +0 -95
@@ -0,0 +1,63 @@
|
|
1
|
+
# Application name
|
2
|
+
|
3
|
+
**Key**: name
|
4
|
+
**Default value**: The directory name of the application's source path
|
5
|
+
|
6
|
+
The name of the application is primarily used for organizational and display purposes. Application names are not included with
|
7
|
+
dependency metadata information included in cached files.
|
8
|
+
|
9
|
+
```yml
|
10
|
+
source_path: path/to/application1
|
11
|
+
name: application1
|
12
|
+
```
|
13
|
+
|
14
|
+
## Dynamically generated application names
|
15
|
+
|
16
|
+
### Source path directory name
|
17
|
+
|
18
|
+
When not specified, an application's name will be the directory name from the application's source path.
|
19
|
+
|
20
|
+
```yml
|
21
|
+
# if not explicitly set the name will be inferred from the source path
|
22
|
+
source_path: path/to/application1
|
23
|
+
# name: application1
|
24
|
+
|
25
|
+
# or, use the `directory_name` name generator to explicitly set this behavior
|
26
|
+
source_path: path/to/application1
|
27
|
+
name:
|
28
|
+
generator: directory_name
|
29
|
+
# name: application1
|
30
|
+
```
|
31
|
+
|
32
|
+
### Relative path from configuration root
|
33
|
+
|
34
|
+
Application names can be created from the path from the configuration root to the application source path.
|
35
|
+
This can be useful when specifying multiple applications using a glob pattern in a directory structure where directory names
|
36
|
+
are not unique.
|
37
|
+
|
38
|
+
As an example, given the following directory structure and configuration YML, the resulting application names
|
39
|
+
would be `linux.installer`, `windows.installer` and `mac.installer`. The optional arguments `separator` and `depth` are used
|
40
|
+
to better control the resulting application name.
|
41
|
+
|
42
|
+
```text
|
43
|
+
path
|
44
|
+
|_to
|
45
|
+
|_linux
|
46
|
+
|_installer
|
47
|
+
|_windows
|
48
|
+
|_installer
|
49
|
+
|_mac
|
50
|
+
|_installer
|
51
|
+
```
|
52
|
+
|
53
|
+
```yml
|
54
|
+
source_path: '**/installer'
|
55
|
+
name:
|
56
|
+
generator: relative_path
|
57
|
+
# separator controls what character separates path parts in the application name
|
58
|
+
# default: "-"
|
59
|
+
separator: '.'
|
60
|
+
# depth controls how many of the path parts are used in the application name
|
61
|
+
# default: 0 / all path parts
|
62
|
+
depth: 2
|
63
|
+
```
|
@@ -0,0 +1,64 @@
|
|
1
|
+
# Application source path
|
2
|
+
|
3
|
+
**Key**: source_path
|
4
|
+
**Default value**:
|
5
|
+
|
6
|
+
- if the `apps` key is not present, then the current working directory where `licensed` was executed
|
7
|
+
- if the `apps` key is present, then `nil`
|
8
|
+
|
9
|
+
The source path is the directory in which licensed should run to enumerate dependencies. This is often dependent
|
10
|
+
on the project type, for example the bundler source should be run from the directory containing a `Gemfile` or `gems.rb`
|
11
|
+
while the go source should be run from the directory containing an entrypoint function.
|
12
|
+
|
13
|
+
The source path is required to run `licensed`. A default value is available only when the configuration file specifies a single application.
|
14
|
+
When multiple applications are configured, each application must specify a source path.
|
15
|
+
|
16
|
+
Paths can be given as absolute or relative paths, and can use special path identifiers. If a relative path is given, it will be based on the application's root path.
|
17
|
+
|
18
|
+
```yml
|
19
|
+
# when apps is not set, a source path does not need to be specified. it will default to the users current directory
|
20
|
+
sources:
|
21
|
+
bundler: true
|
22
|
+
|
23
|
+
# ------
|
24
|
+
# or a path can be given as either an absolute or relative path
|
25
|
+
sources:
|
26
|
+
bundler: true
|
27
|
+
source_path: path/to/application1
|
28
|
+
|
29
|
+
# ------
|
30
|
+
# when apps is set, each application must specify a source_path
|
31
|
+
sources:
|
32
|
+
bundler: true
|
33
|
+
apps:
|
34
|
+
- source_path: relative/path/to/application1
|
35
|
+
- source_path: /absolute/path/to/application2
|
36
|
+
- source_path: ~/path/from/home/to/application3
|
37
|
+
```
|
38
|
+
|
39
|
+
## Expanding source paths with glob patterns
|
40
|
+
|
41
|
+
The `source_path` property can use one or more glob patterns to share configuration properties across multiple application entrypoints.
|
42
|
+
|
43
|
+
For example, there is a common pattern in Go projects to include multiple executable entrypoints under folders in `cmd`. Using a glob pattern allows users to avoid manually configuring and maintaining multiple licensed application `source_path`s. Using a glob pattern will also ensure that any new entrypoints matching the pattern are automatically picked up by licensed commands as they are added.
|
44
|
+
|
45
|
+
```yml
|
46
|
+
sources:
|
47
|
+
go: true
|
48
|
+
|
49
|
+
# treat all directories under `cmd` as separate apps
|
50
|
+
source_path: cmd/*
|
51
|
+
```
|
52
|
+
|
53
|
+
In order to better filter the results from glob patterns, the `source_path` property also accepts an array of
|
54
|
+
inclusion and exclusion glob patterns similar to gitignore files. Inclusion patterns will add matching directory
|
55
|
+
paths to resulting set of source paths, while exclusion patterns will remove matching directory paths.
|
56
|
+
|
57
|
+
```yml
|
58
|
+
source_path:
|
59
|
+
- "projects/*" # include by default all directories under "projects"
|
60
|
+
- "!projects/*Test" # exclude all projects ending in "Test"
|
61
|
+
```
|
62
|
+
|
63
|
+
Glob patterns are syntactic sugar for, and provide the same functionality as, manually specifying multiple `source_path` values.
|
64
|
+
See the instructions on [specifying multiple apps](../configuration.md#specifying-multiple-apps) below for additional considerations when using multiple apps.
|
@@ -0,0 +1,27 @@
|
|
1
|
+
# Configuration root
|
2
|
+
|
3
|
+
**Key**: root
|
4
|
+
**Default value**:
|
5
|
+
|
6
|
+
1. the root of the local git repository, if run inside a git repository
|
7
|
+
1. the directory that `licensed` is run from
|
8
|
+
|
9
|
+
An application's root path is used as the base for any relative configuration paths in the application.
|
10
|
+
|
11
|
+
From a configuration file, the root value can be specified as one of the following. Path string values can contain special path characters.
|
12
|
+
|
13
|
+
- a relative path from the configuration file location
|
14
|
+
- an absolute path
|
15
|
+
- `true` to use the configuration file's directory as the root
|
16
|
+
|
17
|
+
When creating a `Licensed::AppConfiguration` manually with a `root` property, the property must be an absolute path - no path expansion will occur.
|
18
|
+
|
19
|
+
```yml
|
20
|
+
root: path/from/configuration
|
21
|
+
# or
|
22
|
+
root: /absolute/path/to/root
|
23
|
+
# or
|
24
|
+
root: ~/path/from/home/to/root
|
25
|
+
# or
|
26
|
+
root: true
|
27
|
+
```
|
@@ -0,0 +1,58 @@
|
|
1
|
+
# Configuring multiple application definitions
|
2
|
+
|
3
|
+
**Key**: apps
|
4
|
+
**Required**: false
|
5
|
+
|
6
|
+
The configuration file can specify multiple source paths to enumerate metadata, each with their own configuration by using the `apps` key.
|
7
|
+
Each source path and any additional configuration make up an "application". Root configuration settings are inherited into each application,
|
8
|
+
allowing applications to share a common configuration and reducing the overall size of the configuration file.
|
9
|
+
|
10
|
+
When the apps key is not given, the root configuration is treated as a single application.
|
11
|
+
|
12
|
+
```yml
|
13
|
+
apps:
|
14
|
+
# application definition for "go-application"
|
15
|
+
- source_path: path/to/go-application
|
16
|
+
sources:
|
17
|
+
go: true
|
18
|
+
allowed:
|
19
|
+
- mit
|
20
|
+
|
21
|
+
# application definition for "ruby-application"
|
22
|
+
- source_path: path/to/ruby-application
|
23
|
+
sources:
|
24
|
+
bundler: true
|
25
|
+
allowed:
|
26
|
+
- bsd-3-clause
|
27
|
+
```
|
28
|
+
|
29
|
+
## Inheriting configuration
|
30
|
+
|
31
|
+
Applications inherit all root configuration settings. Inherited settings will be overridden by any configuration set directly on the application definition.
|
32
|
+
|
33
|
+
In this example, two apps have been declared. The first app, with `source_path: path/to/application1`, inherits all configuration settings from the root configuration. The second app, with `source_path: path/to/application2`, overrides the `sources` configuration and inherits all other settings.
|
34
|
+
|
35
|
+
```yml
|
36
|
+
sources:
|
37
|
+
go: true
|
38
|
+
bundler: false
|
39
|
+
|
40
|
+
ignored:
|
41
|
+
bundler:
|
42
|
+
- some-internal-gem
|
43
|
+
|
44
|
+
reviewed:
|
45
|
+
bundler:
|
46
|
+
- bcrypt-ruby
|
47
|
+
|
48
|
+
cache_path: 'path/to/cache'
|
49
|
+
apps:
|
50
|
+
# inherits all settings from the root configuration
|
51
|
+
- source_path: 'path/to/application1'
|
52
|
+
|
53
|
+
# inherits all settings except for "sources" from the root configuration
|
54
|
+
- source_path: 'path/to/application2'
|
55
|
+
sources:
|
56
|
+
bundler: true
|
57
|
+
go: false
|
58
|
+
```
|
@@ -0,0 +1,28 @@
|
|
1
|
+
# Specifying dependency sources to use in an application
|
2
|
+
|
3
|
+
**Key**: sources
|
4
|
+
**Required**: false
|
5
|
+
**Default value**: All sources enabled
|
6
|
+
|
7
|
+
The sources configuration property specifies which sources `licensed` will use to enumerate dependencies.
|
8
|
+
By default, `licensed` will try to enumerate dependencies from all sources. As a result,
|
9
|
+
the configuration property should be used to explicitly disable sources rather than to enable a particular source.
|
10
|
+
|
11
|
+
This configuration value does not guarantee that a source will enumerate dependencies. Each
|
12
|
+
configured source's `enabled?` method must return true for licensed to pull dependency information.
|
13
|
+
|
14
|
+
`licensed` determines which sources will try to enumerate dependencies based on the following rules:
|
15
|
+
|
16
|
+
1. If no sources are configured, all sources are enabled
|
17
|
+
2. If no sources are set to true, any unconfigured sources are enabled
|
18
|
+
3. If any sources are set to true, any unconfigured sources are disabled
|
19
|
+
|
20
|
+
```yml
|
21
|
+
# all other sources are enabled by default since there are no sources set to true
|
22
|
+
sources:
|
23
|
+
bower: false
|
24
|
+
|
25
|
+
# all other sources are disabled by default because a source was set to true
|
26
|
+
sources:
|
27
|
+
bower: true
|
28
|
+
```
|
@@ -0,0 +1,19 @@
|
|
1
|
+
# Ignoring dependencies
|
2
|
+
|
3
|
+
**Key**: ignored
|
4
|
+
**Default value**: none
|
5
|
+
|
6
|
+
This configuration property is used to fully ignore a dependency during all `licensed` commands. Any dependency on this list will not
|
7
|
+
be enumerated, or have its metadata cached or checked for compliance. This is intended for dependencies that do not require attribution
|
8
|
+
or compliance checking - internal or 1st party dependencies, or dependencies that do not ship with the product such as test frameworks.
|
9
|
+
|
10
|
+
The ignored dependency list is organized based on the dependency source type - `bundler`, `go`, etc. Add a dependency's metadata identifier to the appropriate source type sub-property to cause `licensed` to no longer take action on the dependency. Glob patterns can be used to identify multiple internal dependencies without having to manage a large list.
|
11
|
+
|
12
|
+
```yml
|
13
|
+
ignored:
|
14
|
+
bundler:
|
15
|
+
- my-internal-gem
|
16
|
+
- my-first-party-gem
|
17
|
+
go:
|
18
|
+
- github.com/me/my-repo/**/*
|
19
|
+
```
|
@@ -0,0 +1,106 @@
|
|
1
|
+
# Dependency metadata cache
|
2
|
+
|
3
|
+
**Key**: cache_path
|
4
|
+
**Default value**: .licenses
|
5
|
+
|
6
|
+
The cache path is the root directory where `licensed` will write cached metadata files for each dependency.
|
7
|
+
By default, files will be written to a folder under the cache path in a structure like:
|
8
|
+
|
9
|
+
```text
|
10
|
+
<cache path>
|
11
|
+
|_<source name>
|
12
|
+
|_<dependency identifier>.dep.yml
|
13
|
+
```
|
14
|
+
|
15
|
+
Cache paths can be given as an absolute or relative path and can contain special path characters
|
16
|
+
|
17
|
+
```yml
|
18
|
+
cache_path: relative/path/to/cache
|
19
|
+
# or
|
20
|
+
cache_path: /absolute/path/to/cache
|
21
|
+
# or
|
22
|
+
cache_path: ~/path/from/home/to/cache
|
23
|
+
```
|
24
|
+
|
25
|
+
## Configuring caches for multiple applications
|
26
|
+
|
27
|
+
When multiple applications are specified in a configuration file caches can be shared, inherited and explicitly configured.
|
28
|
+
Unless otherwise specified, preference is given based on the locality and intention of the configuration options.
|
29
|
+
|
30
|
+
1. explicitly configured cache paths are preferred to inherited or shared cache paths
|
31
|
+
2. shared cache paths are preferred to inherited cache paths
|
32
|
+
3. cache paths that are not otherwise set by an application will be inherited from the root configuration
|
33
|
+
|
34
|
+
### Explicit cache usage for multiple applications
|
35
|
+
|
36
|
+
Individual applications in a multi-application configuration can explicitly set cache paths.
|
37
|
+
|
38
|
+
```yml
|
39
|
+
apps:
|
40
|
+
- source_path: path/to/application1
|
41
|
+
cache_path: path/to/application1/.licenses
|
42
|
+
- source_path: path/to/application2
|
43
|
+
cache_path: path/to/application2/.licenses
|
44
|
+
```
|
45
|
+
|
46
|
+
### Sharing a single cache for multiple applications
|
47
|
+
|
48
|
+
Sharing a cache across multiple applications is possible by setting `cache_path: <path>` and `shared_cache: true` at the root level.
|
49
|
+
Individual applications can opt out of sharing a cache by explicitly setting a cache path.
|
50
|
+
|
51
|
+
```yml
|
52
|
+
shared_cache: true
|
53
|
+
cache_path: .cache/shared
|
54
|
+
apps:
|
55
|
+
# application1 and application2 will share a cache at .cache/shared
|
56
|
+
- source_path: path/to/application1
|
57
|
+
- source_path: path/to/application2
|
58
|
+
# application3 will use a separate cache at .cache/application3
|
59
|
+
- source_path: path/to/application3
|
60
|
+
cache_path: .cache/application3
|
61
|
+
```
|
62
|
+
|
63
|
+
This is equivalent to explicitly configuring the same cache for many applications
|
64
|
+
|
65
|
+
```yaml
|
66
|
+
apps:
|
67
|
+
- source_path: "path/to/application1"
|
68
|
+
cache_path: ".cache/shared"
|
69
|
+
- source_path: "path/to/application2"
|
70
|
+
cache_path: ".cache/shared"
|
71
|
+
```
|
72
|
+
|
73
|
+
Using the `shared_cache` key is primarily useful when specifying `source_path` as a glob pattern.
|
74
|
+
|
75
|
+
```yml
|
76
|
+
shared_cache: true
|
77
|
+
cache_path: .cache/shared
|
78
|
+
source_path: path/to/*
|
79
|
+
```
|
80
|
+
|
81
|
+
### Inheriting cache usage from the root configuration
|
82
|
+
|
83
|
+
When not otherwise specified, applications will inherit a cache path from the root configuration.
|
84
|
+
If the root configuration does not explicitly set a cache path value, the default cache path value is used.
|
85
|
+
|
86
|
+
Inherited cache paths are treated as the root location for each application's metadata cache. Each application
|
87
|
+
will store metadata in a named subdirectory of the root location to avoid file path clashes between
|
88
|
+
applications.
|
89
|
+
|
90
|
+
```yml
|
91
|
+
# optional. if not specified, the default value `.licenses` will be used
|
92
|
+
cache_path: .cache
|
93
|
+
apps:
|
94
|
+
- source_path: path/to/application1
|
95
|
+
- source_path: path/to/application2
|
96
|
+
```
|
97
|
+
|
98
|
+
```text
|
99
|
+
.cache
|
100
|
+
|_application1
|
101
|
+
|_<source type>
|
102
|
+
|_<dependency identifier>.dep.yml
|
103
|
+
|_application2
|
104
|
+
|_<source type>
|
105
|
+
|_<dependency identifier>.dep.yml
|
106
|
+
```
|
@@ -0,0 +1,18 @@
|
|
1
|
+
# Reviewing dependencies
|
2
|
+
|
3
|
+
**Key**: reviewed
|
4
|
+
**Default value**: none
|
5
|
+
|
6
|
+
Sometimes your projects will use a dependency with an OSS license that you don't want to globally allow but can use with individual review.
|
7
|
+
The list of reviewed dependencies is meant to cover this scenario and will prevent the status command from raising an error for
|
8
|
+
a dependency with a license not on the allowed list.
|
9
|
+
|
10
|
+
The reviewed dependency list is organized based on the dependency source type - `bundler`, `go`, etc. Add a dependency's metadata identifier to the appropriate source type sub-property to cause `licensed` to ignore license compliance failures. Glob patterns can be used to identify multiple internal dependencies without having to manage a large list.
|
11
|
+
|
12
|
+
_NOTE: marking a dependency as reviewed will not prevent licensed from raising an error on missing license information._
|
13
|
+
|
14
|
+
```yml
|
15
|
+
reviewed:
|
16
|
+
bundler:
|
17
|
+
- gem-using-unallowed-license
|
18
|
+
```
|
@@ -1,3 +1,3 @@
|
|
1
|
-
# Migrating your licensed configuration and cached records to
|
1
|
+
# Migrating your licensed configuration and cached records to licensed v2
|
2
2
|
|
3
3
|
Licensed v2+ ships with an additional executable, `licensed-migrator`, that can be used to update your licensed files to the format expected by the currently installed version. To run, execute `licensed migrate --from v1 -c <path to licensed configuration file>`, replacing `v1` with the major version of licensed to migrate from.
|
@@ -0,0 +1,109 @@
|
|
1
|
+
# Breaking changes to bundler dependency enumeration in v3
|
2
|
+
|
3
|
+
**NOTE** If you are migrating from a version earlier than v2, please first [migrate to v2](./v2.md) before continuing.
|
4
|
+
|
5
|
+
Licensed v3 includes a breaking change to bundler dependency enumeration when using the executable form of licensed. Bundler dependency enumeration will no longer work with the licensed executable as of 3.0.0.
|
6
|
+
|
7
|
+
**If your project does not use bundler, or if you already install the licensed gem, you are not affected by this breaking change.**
|
8
|
+
|
9
|
+
## Migrating bundler enumeration for v3
|
10
|
+
|
11
|
+
When using licensed v3 with bundler dependencies, licensed must be installed from its [gem](https://rubygems.org/gems/licensed). This can be accomplished with `gem install`, or by adding licensed to a bundler gem file.
|
12
|
+
|
13
|
+
### Usage in a GitHub Actions workflow
|
14
|
+
|
15
|
+
Using licensed to enumerate bundler dependencies in a GitHub Actions workflow will require ruby to be available in the actions VM environment. Ruby can be setup in an actions workflow using [ruby/setup-ruby](https://github.com/ruby/setup-ruby)(preferred) or [actions/setup-ruby](https://github.com/actions/setup-ruby)(deprecated).
|
16
|
+
|
17
|
+
If you are using licensed in a GitHub Actions workflow, [jonabc/setup-licensed](https://github.com/jonabc/setup-licensed) has been updated according to this breaking change. `setup-licensed` will install the licensed gem when ruby is available, or the licensed executable when ruby is not available. Alternatively, you can `gem install` licensed directly as an actions step.
|
18
|
+
|
19
|
+
This is an example workflow definition that runs [jonabc/licensed-ci](https://github.com/jonabc/licensed-ci)'s opinionated license compliance workflow in CI. It includes jobs that demonstrate installing licensed using
|
20
|
+
- `gem install`
|
21
|
+
- [jonabc/setup-licensed](https://github.com/jonabc/setup-licensed)
|
22
|
+
- installing when included in a bundler gem file
|
23
|
+
|
24
|
+
```yml
|
25
|
+
name: Cache and verify dependency license metadata
|
26
|
+
|
27
|
+
on:
|
28
|
+
# run when PRs are opened, reopened or updated
|
29
|
+
pull_request:
|
30
|
+
types:
|
31
|
+
- opened
|
32
|
+
- reopened
|
33
|
+
- synchronize
|
34
|
+
|
35
|
+
# run on demand
|
36
|
+
workflow_dispatch:
|
37
|
+
|
38
|
+
jobs:
|
39
|
+
# install licensed with setup-licensed
|
40
|
+
licensed-ci-setup-licensed:
|
41
|
+
runs-on: ubuntu-latest
|
42
|
+
|
43
|
+
steps:
|
44
|
+
# checkout the repo
|
45
|
+
- uses: actions/checkout@v1
|
46
|
+
|
47
|
+
# install ruby
|
48
|
+
- uses: ruby/setup-ruby@v1
|
49
|
+
with:
|
50
|
+
ruby-version: "3.0"
|
51
|
+
|
52
|
+
# install licensed gem using setup-licensed
|
53
|
+
- uses: jonabc/setup-licensed@v1
|
54
|
+
with:
|
55
|
+
version: '3.x'
|
56
|
+
|
57
|
+
# install dependencies in CI environment
|
58
|
+
- run: bundle install
|
59
|
+
|
60
|
+
# run licensed-ci to cache any metadata changes and verify compliance
|
61
|
+
- uses: jonabc/licensed-ci@v1
|
62
|
+
|
63
|
+
# OR
|
64
|
+
|
65
|
+
# install licensed using gem install
|
66
|
+
licensed-ci-gem:
|
67
|
+
runs-on: ubuntu-latest
|
68
|
+
|
69
|
+
steps:
|
70
|
+
# checkout the repo
|
71
|
+
- uses: actions/checkout@v1
|
72
|
+
|
73
|
+
# install ruby and bundler
|
74
|
+
- uses: ruby/setup-ruby@v1
|
75
|
+
with:
|
76
|
+
ruby-version: "3.0"
|
77
|
+
|
78
|
+
# install licensed gem using setup-licensed
|
79
|
+
- run: gem install licensed -v '~> 3.0'
|
80
|
+
|
81
|
+
# install dependencies in CI environment
|
82
|
+
- run: bundle install
|
83
|
+
|
84
|
+
# run licensed-ci to cache any metadata changes and verify compliance
|
85
|
+
- uses: jonabc/licensed-ci@v1
|
86
|
+
|
87
|
+
# OR
|
88
|
+
|
89
|
+
# install licensed as part of bundle installation
|
90
|
+
licensed-ci-bundle:
|
91
|
+
runs-on: ubuntu-latest
|
92
|
+
|
93
|
+
steps:
|
94
|
+
# checkout the repo
|
95
|
+
- uses: actions/checkout@v1
|
96
|
+
|
97
|
+
# install ruby and bundler
|
98
|
+
- uses: ruby/setup-ruby@v1
|
99
|
+
with:
|
100
|
+
ruby-version: "3.0"
|
101
|
+
|
102
|
+
# install licensed and other dependencies in CI environment
|
103
|
+
- run: bundle install
|
104
|
+
|
105
|
+
# run licensed-ci to cache any metadata changes and verify compliance
|
106
|
+
- uses: jonabc/licensed-ci@v1
|
107
|
+
with:
|
108
|
+
command: 'bundle exec licensed' # run licensed within the bundler context
|
109
|
+
```
|