Mirrors/inspec
2
0
Fork 0
mirror of https://github.com/inspec/inspec synced 2024-11-10 07:04:15 +00:00
Code Issues Projects Releases Packages Wiki Activity

Sync up the default branch as main (#6239) (#6455)

Browse source 
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
Co-authored-by: Takuya N <takninnovationresearch@gmail.com>
This commit is contained in:
Vasundhara Jagdale 2023-02-24 14:20:00 +05:30 committed by GitHub
parent c72b757945
commit ecce508ee0
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
14 changed files with 44 additions and 43 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
.github/ISSUE_TEMPLATE.md vendored
View file

@ -2,7 +2,7 @@
**Choose one:** is this a 🐛 bug report or 🙋 feature request?
Briefly describe the issue and the expected behavior. Also, please be aware of our [Code of Conduct](https://github.com/inspec/inspec/blob/master/CODE_OF_CONDUCT.md).
Briefly describe the issue and the expected behavior. Also, please be aware of our [Code of Conduct](https://github.com/inspec/inspec/blob/main/CODE_OF_CONDUCT.md).
### 🌍 InSpec and Platform Version

8
CONTRIBUTING.md
View file

@ -2,7 +2,7 @@
We are glad you want to contribute to InSpec! This document will help answer common questions you may have during your first contribution.
As a reminder, all participants are expected to follow the [Code of Conduct](https://github.com/inspec/inspec/blob/master/CODE_OF_CONDUCT.md).
As a reminder, all participants are expected to follow the [Code of Conduct](https://github.com/inspec/inspec/blob/main/CODE_OF_CONDUCT.md).
## Submitting Issues
@ -25,13 +25,13 @@ We have a 3 step process for contributions:
Chef Projects are built to last. We strive to ensure high quality throughout the experience. In order to ensure this, we require that all pull requests to Chef projects meet these specifications:
1. **Tests:** To ensure high quality code and protect against future regressions, we require all the code in Chef Projects to have at least unit test coverage. See the [test/unit](https://github.com/inspec/inspec/tree/master/test/unit)
1. **Tests:** To ensure high quality code and protect against future regressions, we require all the code in Chef Projects to have at least unit test coverage. See the [test/unit](https://github.com/inspec/inspec/tree/main/test/unit)
directory for the existing tests and use ```bundle exec rake test``` to run them. It should be good to know InSpec uses [minitest](https://github.com/seattlerb/minitest) as a testing framework.
2. **Green CI Tests:** We use [Travis CI](https://travis-ci.org/) and/or [AppVeyor](https://www.appveyor.com/) CI systems to test all pull requests. We require these test runs to succeed on every pull request before being merged.
3. **Up-to-date Documentation:** Every code change should be reflected in an update for our [documentation](https://github.com/inspec/inspec/tree/master/docs-chef-io). We expect PRs to update the documentation with the code change.
3. **Up-to-date Documentation:** Every code change should be reflected in an update for our [documentation](https://github.com/inspec/inspec/tree/main/docs-chef-io). We expect PRs to update the documentation with the code change.
In addition to this it would be nice to include the description of the problem you are solving
with your change. You can use [Issue Template](https://github.com/inspec/inspec/tree/master/ISSUE_TEMPLATE.md) in the description section
with your change. You can use [Issue Template](https://github.com/inspec/inspec/tree/main/ISSUE_TEMPLATE.md) in the description section
of the pull request.
### Code Review Process

19
README.md
View file

@ -4,10 +4,11 @@
* **Issues Response SLA: 14 business days**
* **Pull Request Response SLA: 14 business days**
For more information on project states and SLAs, see [this documentation](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md).
For more information on project states and SLAs, see [this documentation](https://github.com/chef/chef-oss-practices/blob/main/repo-management/repo-states.md).
[![Build status](https://badge.buildkite.com/bf4c5fdc3858cc9f8c8bab8376e8e40d625ad046df9d4d8619.svg?branch=master)](https://buildkite.com/chef-oss/inspec-inspec-master-verify)
[![Coverage Status](https://coveralls.io/repos/github/inspec/inspec/badge.svg?branch=master)](https://coveralls.io/github/inspec/inspec?branch=master)
[![Slack](https://community-slack.chef.io/badge.svg)](https://community-slack.chef.io/)
[![Build status](https://badge.buildkite.com/bf4c5fdc3858cc9f8c8bab8376e8e40d625ad046df9d4d8619.svg?branch=main)](https://buildkite.com/chef-oss/inspec-inspec-main-verify)
[![Coverage Status](https://coveralls.io/repos/github/inspec/inspec/badge.svg?branch=main)](https://coveralls.io/github/inspec/inspec?branch=main)
Chef InSpec is an open-source testing framework for infrastructure with a human- and machine-readable language for specifying compliance, security and policy requirements.
@ -223,10 +224,10 @@ end
```
Also have a look at our examples for:
- [Using Chef InSpec with Test Kitchen & Chef Infra](https://github.com/chef/inspec/tree/master/examples/kitchen-chef)
- [Using Chef InSpec with Test Kitchen & Puppet](https://github.com/chef/inspec/tree/master/examples/kitchen-puppet)
- [Using Chef InSpec with Test Kitchen & Ansible](https://github.com/chef/inspec/tree/master/examples/kitchen-ansible)
- [Implementing an Chef InSpec profile](https://github.com/chef/inspec/tree/master/examples/profile)
- [Using Chef InSpec with Test Kitchen & Chef Infra](https://github.com/chef/inspec/tree/main/examples/kitchen-chef)
- [Using Chef InSpec with Test Kitchen & Puppet](https://github.com/chef/inspec/tree/main/examples/kitchen-puppet)
- [Using Chef InSpec with Test Kitchen & Ansible](https://github.com/chef/inspec/tree/main/examples/kitchen-ansible)
- [Implementing an Chef InSpec profile](https://github.com/chef/inspec/tree/main/examples/profile)
## Or tests: Testing for a OR b
@ -349,7 +350,7 @@ Documentation
* https://docs.chef.io/inspec/
* https://docs.chef.io/inspec/resources/
* https://github.com/inspec/inspec/tree/master/docs-chef-io
* https://github.com/inspec/inspec/tree/main/docs-chef-io
Learn Chef:
@ -385,7 +386,7 @@ The Chef InSpec community and maintainers are very active and helpful. This proj
If you'd like to chat with the community and maintainers directly join us in the `#inspec` channel on the [Chef Community Slack](http://community-slack.chef.io/).
As a reminder, all participants are expected to follow the [Code of Conduct](https://github.com/inspec/inspec/blob/master/CODE_OF_CONDUCT.md).
As a reminder, all participants are expected to follow the [Code of Conduct](https://github.com/inspec/inspec/blob/main/CODE_OF_CONDUCT.md).
[![Slack](https://community-slack.chef.io/badge.svg)](https://community-slack.chef.io/)

12
RELEASE_PROCESS.md
View file

@ -46,7 +46,7 @@ Connect to the Chef VPN to fetch Expeditor logs in the event of a failure.
### Check Expeditor Labels
Most, though not all, PRs should not have any Expeditor control labels. The patchlevel (4.18.X) will be automatically incremented by the [expeditor configuration](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L117) and the [version bump script](https://github.com/inspec/inspec/blob/master/.expeditor/update_version.sh).
Most, though not all, PRs should not have any Expeditor control labels. The patchlevel (4.18.X) will be automatically incremented by the [expeditor configuration](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L117) and the [version bump script](https://github.com/inspec/inspec/blob/main/.expeditor/update_version.sh).
Here are the Expeditor control labels, and the circumstances under which they should be used:
@ -66,7 +66,7 @@ You'll see a message in #inspec-notify from Expeditor that it "performed actions
### Watch Omnibus Build
The Omnibus build creates operating-system-specific packages for each platform on which we release Chef InSpec. Its [expeditor configuration](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L133) drives a [Buildkite configuration](https://github.com/inspec/inspec/blob/master/.expeditor/release.omnibus.yml), which lists exactly which platforms to build.
The Omnibus build creates operating-system-specific packages for each platform on which we release Chef InSpec. Its [expeditor configuration](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L133) drives a [Buildkite configuration](https://github.com/inspec/inspec/blob/main/.expeditor/release.omnibus.yml), which lists exactly which platforms to build.
The Omnibus build is generally reliable, if somewhat slow.
@ -74,7 +74,7 @@ When the omnibus build succeeds, omnitruck delivers the packages to various pack
### Watch Chef Habitat Build
The Chef Habitat build creates Habitat .hart packages for Linux and Windows. The [Expeditor configuration](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L138) drives a [Buildkite configuration](https://github.com/inspec/inspec/blob/master/.expeditor/build.habitat.yml).
The Chef Habitat build creates Habitat .hart packages for Linux and Windows. The [Expeditor configuration](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L138) drives a [Buildkite configuration](https://github.com/inspec/inspec/blob/main/.expeditor/build.habitat.yml).
The Chef Habitat build is unreliable, usually due to network timeouts on the Windows machines. It often requires manual retries by clicking the retry button in Buildkite. You can find the link to try a manual retry from the message posted by Expeditor in #inspec-notify. If you do not retry, later steps will fail.
@ -82,7 +82,7 @@ When the hab build succeeds, the packages will be placed on the Hab builder in t
### Docker Image Built and Released
We also release a Docker image (see [expeditor config](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L150)), which contains an Alpine system and Chef InSpec installed from a gem, with the ENTRYPOINT of the Docker image being `inspec` (see [Dockerfile](https://github.com/inspec/inspec/blob/master/Dockerfile)). It's a simple way to ship the dependencies of `inspec`.
We also release a Docker image (see [expeditor config](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L150)), which contains an Alpine system and Chef InSpec installed from a gem, with the ENTRYPOINT of the Docker image being `inspec` (see [Dockerfile](https://github.com/inspec/inspec/blob/main/Dockerfile)). It's a simple way to ship the dependencies of `inspec`.
When it succeeds, the Docker build is labeled as `current`. Currently, there is nothing that promotes the Docker image to the `stable` label ([#4952](https://github.com/inspec/inspec/issues/4952)).
@ -168,7 +168,7 @@ inspec/inspec:master performed the following actions for inspec 4.18.100 (stable
• Notified Slack channels of the artifact_published event
```
Among other things, this promotion automatically generates [release notes](https://github.com/inspec/inspec/blob/master/.expeditor/publish-release-notes.sh) and [publishes them](https://github.com/inspec/inspec/blob/master/.expeditor/announce-release.sh) to Discourse.
Among other things, this promotion automatically generates [release notes](https://github.com/inspec/inspec/blob/master/.expeditor/publish-release-notes.sh) and [publishes them](https://github.com/inspec/inspec/blob/main/.expeditor/announce-release.sh) to Discourse.
### Update chef/homebrew-chef
@ -177,5 +177,5 @@ This should be merged - at some point this could be changed to directly committi
## Updating InSpec Docs on docs.chef.io
See the [README](https://github.com/inspec/inspec/blob/master/docs-chef-io/README.md#update-the-inspec-repository-module-in-chefchef-web-docs) for instructions on
See the [README](https://github.com/inspec/inspec/blob/main/docs-chef-io/README.md#update-the-inspec-repository-module-in-chefchef-web-docs) for instructions on
updating the current InSpec documentation on docs.chef.io.

20
dev-docs/ci-cd.md
View file

@ -4,7 +4,7 @@
### Expeditor
[Expeditor](https://expeditor.chef.io/) is the main coordinator of all CI-CD activity at Chef. It is configured through a [YAML file](https://github.com/inspec/inspec/blob/master/.expeditor/config.yml).
[Expeditor](https://expeditor.chef.io/) is the main coordinator of all CI-CD activity at Chef. It is configured through a [YAML file](https://github.com/inspec/inspec/blob/main/.expeditor/config.yml).
### BuildKite
@ -16,13 +16,13 @@ You will need to have an account on BuildKite and be a member of both orgs to fu
### Rakefile
The [Rakefile](https://github.com/inspec/inspec/blob/master/Rakefile) defines the tests harness to be run. Most of the test scripts come down to executing "rake test" or similar.
The [Rakefile](https://github.com/inspec/inspec/blob/main/Rakefile) defines the tests harness to be run. Most of the test scripts come down to executing "rake test" or similar.
### Omnibus
Omnibus is a system for building OS-specific packages of software, including all dependencies including Ruby runtimes. We use Omnibus to make RPMs, DEBs, MSIs, DMGs, and several other OS-specific formats that deploy inspec and its dependencies natively to the OS.
The omnibus configuration for InSpec is stored at https://github.com/inspec/inspec/tree/master/omnibus and the main configuration file is [inspec.rb](https://github.com/inspec/inspec/blob/master/omnibus/config/projects/inspec.rb).
The omnibus configuration for InSpec is stored at https://github.com/inspec/inspec/tree/master/omnibus and the main configuration file is [inspec.rb](https://github.com/inspec/inspec/blob/main/omnibus/config/projects/inspec.rb).
### Rubygems
@ -46,13 +46,13 @@ One default pipeline that gets activated is the Buildkite [master verify pipelin
The verify pipeline runs the linter, the unit tests, and the functional tests. It verifies that the code being submitted is sound.
The verify pipeline is defined first in the [verify.pipeline.yml](https://github.com/inspec/inspec/blob/master/.expeditor/verify.pipeline.yml) file, which defines the separate Ruby versions, platforms, and environment variables to be passed to each one. Each runner calls a shell script, either [verify.sh](https://github.com/inspec/inspec/blob/master/.expeditor/buildkite/verify.sh) or [verify.ps1](https://github.com/inspec/inspec/blob/master/.expeditor/buildkite/verify.ps1). These scripts are thin wrappers that install Bundler dependencies from a cache, then call into the Rakefile.
The verify pipeline is defined first in the [verify.pipeline.yml](https://github.com/inspec/inspec/blob/master/.expeditor/verify.pipeline.yml) file, which defines the separate Ruby versions, platforms, and environment variables to be passed to each one. Each runner calls a shell script, either [verify.sh](https://github.com/inspec/inspec/blob/master/.expeditor/buildkite/verify.sh) or [verify.ps1](https://github.com/inspec/inspec/blob/main/.expeditor/buildkite/verify.ps1). These scripts are thin wrappers that install Bundler dependencies from a cache, then call into the Rakefile.
#### habitat artifact pipeline
The habitat artifact pipeline runs a smoke test to verify that the habitat build of inspec is valid.
The habitat artifact pipeline is defined first in the [artifact.habitat.yml](https://github.com/inspec/inspec/blob/master/.expeditor/artifact.habitat.yml) file. It simply defines a linux runner and a windows runner, each with a dedicated script, [artifact.habitat.test.sh](https://github.com/inspec/inspec/blob/master/.expeditor/buildkite/artifact.habitat.test.sh) or [artifact.habitat.test.ps1](https://github.com/inspec/inspec/blob/master/.expeditor/buildkite/artifact.habitat.test.ps1). The scripts install habitat, setup an origin key, build the package, and then run a [Rakefile](https://github.com/inspec/inspec/blob/master/test/artifact/Rakefile)
The habitat artifact pipeline is defined first in the [artifact.habitat.yml](https://github.com/inspec/inspec/blob/master/.expeditor/artifact.habitat.yml) file. It simply defines a linux runner and a windows runner, each with a dedicated script, [artifact.habitat.test.sh](https://github.com/inspec/inspec/blob/master/.expeditor/buildkite/artifact.habitat.test.sh) or [artifact.habitat.test.ps1](https://github.com/inspec/inspec/blob/master/.expeditor/buildkite/artifact.habitat.test.ps1). The scripts install habitat, setup an origin key, build the package, and then run a [Rakefile](https://github.com/inspec/inspec/blob/main/test/artifact/Rakefile)
### A PR is merged
@ -67,7 +67,7 @@ Connect to the Progress VPN to fetch Expeditor logs in the event of a failure.
This is controlled by the `built_in:bump_version` and `bash:.expeditor/update_version.sh` subscriptions.
If there are no GitHub labels on the PR, the patchlevel of the version will be bumped by executing the [.expeditor/update_version.sh](https://github.com/inspec/inspec/blob/master/.expeditor/update_version.sh) script. First the VERSION file is updated, then the script runs to update the versions in the Ruby files.
If there are no GitHub labels on the PR, the patchlevel of the version will be bumped by executing the [.expeditor/update_version.sh](https://github.com/inspec/inspec/blob/main/.expeditor/update_version.sh) script. First the VERSION file is updated, then the script runs to update the versions in the Ruby files.
`built_in:bump_version` is in charge of bumping versions in VERSION, and is controlled by GitHub labels on the PR. Most, though not all, PRs should not have any Expeditor control labels.
@ -81,7 +81,7 @@ Here are the Expeditor control labels, and the circumstances under which they sh
This is controlled by the `trigger_pipeline:omnibus/release` subscription.
The Omnibus build creates operating-system-specific packages for each platform on which we release Chef InSpec. Its [expeditor configuration](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L133) drives a [Buildkite configuration](https://github.com/inspec/inspec/blob/master/.expeditor/release.omnibus.yml), which lists exactly which platforms to build.
The Omnibus build creates operating-system-specific packages for each platform on which we release Chef InSpec. Its [expeditor configuration](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L133) drives a [Buildkite configuration](https://github.com/inspec/inspec/blob/main/.expeditor/release.omnibus.yml), which lists exactly which platforms to build.
The Omnibus build is generally reliable, if somewhat slow.
@ -89,13 +89,13 @@ When the omnibus build succeeds, omnitruck delivers the packages to various pack
#### Chef Habitat Build
The Chef Habitat build creates Habitat .hart packages for Linux and Windows. The [Expeditor configuration](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L138) drives a [Buildkite configuration](https://github.com/inspec/inspec/blob/master/.expeditor/build.habitat.yml).
The Chef Habitat build creates Habitat .hart packages for Linux and Windows. The [Expeditor configuration](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L138) drives a [Buildkite configuration](https://github.com/inspec/inspec/blob/main/.expeditor/build.habitat.yml).
When the hab build succeeds, the packages will be placed on the Hab builder in the `unstable` channel for public consumption.
#### Docker Image Built and Released
We also release a Docker image (see [expeditor config](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L150)), which contains a Linux system and Chef InSpec installed from a gem, with the ENTRYPOINT of the Docker image being `inspec` (see [Dockerfile](https://github.com/inspec/inspec/blob/master/Dockerfile)). It's a simple way to ship the dependencies of `inspec`.
We also release a Docker image (see [expeditor config](https://github.com/inspec/inspec/blob/44fe144732e1e0abb2594957a880c5f1821e7774/.expeditor/config.yml#L150)), which contains a Linux system and Chef InSpec installed from a gem, with the ENTRYPOINT of the Docker image being `inspec` (see [Dockerfile](https://github.com/inspec/inspec/blob/main/Dockerfile)). It's a simple way to ship the dependencies of `inspec`.
When it succeeds, the Docker build is labeled as `current`.
@ -126,7 +126,7 @@ The gems are taken from Artifactory and published to Rubygems.org. This is done
#### Release notes are published
The [pending release notes](https://github.com/inspec/inspec/wiki/Pending-Release-Notes) are copied to AWS S3 by a [script](https://github.com/inspec/inspec/blob/master/.expeditor/publish-release-notes.sh), and then reset back to an empty state. Another [script](https://github.com/inspec/inspec/blob/master/.expeditor/announce-release.sh) takes the release notes from S3 and creates a post on Discourse.
The [pending release notes](https://github.com/inspec/inspec/wiki/Pending-Release-Notes) are copied to AWS S3 by a [script](https://github.com/inspec/inspec/blob/master/.expeditor/publish-release-notes.sh), and then reset back to an empty state. Another [script](https://github.com/inspec/inspec/blob/main/.expeditor/announce-release.sh) takes the release notes from S3 and creates a post on Discourse.

10
dev-docs/control-eval.md
View file

@ -27,7 +27,7 @@ Profile context gets instantiated as soon as the Profile gets created.
#11 Inspec::InspecCLI.exec(*targets#Array) at inspec/lib/inspec/cli.rb:283
When run method of the runner gets called, it loads control [file](https://github.com/inspec/inspec/blob/master/lib/inspec/profile_context.rb#L151) which instantiates the control_eval_context object [here](https://github.com/inspec/inspec/blob/master/lib/inspec/profile_context.rb#L61) and creates dsl, and the adds profile_context as dsl class methods [here](https://github.com/inspec/inspec/blob/master/lib/inspec/profile_context.rb#L243)
When run method of the runner gets called, it loads control [file](https://github.com/inspec/inspec/blob/master/lib/inspec/profile_context.rb#L151) which instantiates the control_eval_context object [here](https://github.com/inspec/inspec/blob/master/lib/inspec/profile_context.rb#L61) and creates dsl, and the adds profile_context as dsl class methods [here](https://github.com/inspec/inspec/blob/main/lib/inspec/profile_context.rb#L243)
#0 Inspec::ProfileContext::DomainSpecificLunacy::ClassMethods.add_methods(profile_context#Inspec::ProfileContext) at /inspec/lib/inspec/profile_context.rb:242
#1 block in #<Class:Inspec::ProfileContext::DomainSpecificLunacy>.block in create_dsl(profile_context#Inspec::ProfileContext) at /inspec/lib/inspec/profile_context.rb:220
@ -50,11 +50,11 @@ When run method of the runner gets called, it loads control [file](https://githu
### DSL methods are executed at this time
So, if you have a control file with `title` in it, that will call the title method that was defined [here](https://github.com/inspec/inspec/blob/master/lib/inspec/control_eval_context.rb#L46). Importantly, this also includes the `control` DSL keyword, and also the `describe` keyword (used for bare describes).
So, if you have a control file with `title` in it, that will call the title method that was defined [here](https://github.com/inspec/inspec/blob/main/lib/inspec/control_eval_context.rb#L46). Importantly, this also includes the `control` DSL keyword, and also the `describe` keyword (used for bare describes).
### Each control get registered as rule.
Each control gets registerd and the terminology switches from `control` to `rule` [here](https://github.com/inspec/inspec/blob/master/lib/inspec/control_eval_context.rb#L57)
Each control gets registerd and the terminology switches from `control` to `rule` [here](https://github.com/inspec/inspec/blob/main/lib/inspec/control_eval_context.rb#L57)
The control context class also gets extended with the resource DSL, so anything in the source code for the control can use the resource DSL. This includes all resource names, but importantly, the `describe` DSL keyword.
@ -62,7 +62,7 @@ Finally, Inspec::Rule provides the control DSL - impact, title, desc, ref, and t
### The block is instance_eval'd against the control context class
See `https://github.com/inspec/inspec/blob/master/lib/inspec/rule.rb#L46`. We're now in two levels of instance eval'ing - the file is gradually being eval'd against the profile context and the current control's block is being instance eval'd against a control context.
See `https://github.com/inspec/inspec/blob/main/lib/inspec/rule.rb#L46`. We're now in two levels of instance eval'ing - the file is gradually being eval'd against the profile context and the current control's block is being instance eval'd against a control context.
At this stage, control-level metadata (impact, title, refs, tags, desc) are evaluated and set as instance vars on the control.
@ -76,7 +76,7 @@ And, the describe and describe.one blocks are executed.
Using the method register_control (dynamically defined on the control eval context), we check for various skip conditions. If none of them apply, the control is then registered with the profile context using register_rule.
[ProfileContext.register_rule's](https://github.com/inspec/inspec/blob/master/lib/inspec/profile_context.rb#L183) main job is to determine the full ID of the control (within the context of the profile) and either add it to the controls list, or (if another control with the same ID exists), merge it. (This is where overriding happens).
[ProfileContext.register_rule's](https://github.com/inspec/inspec/blob/main/lib/inspec/profile_context.rb#L183) main job is to determine the full ID of the control (within the context of the profile) and either add it to the controls list, or (if another control with the same ID exists), merge it. (This is where overriding happens).
Note: can skip a control with:
Inspec::Rule.set_skip_rule(control, msg)

2
dev-docs/plugins.md
View file

@ -760,7 +760,7 @@ One useful thing you can do is create macros for generating controls: the `contr
#### Control DSL Context
When your mixin method is called, `self` will be an instance of an anonymous class representing the control being executed; each control gets its own anonymous class. The parent class of the anonymous class will be [Inspec::Rule](https://github.com/inspec/inspec/blob/master/lib/inspec/rule.rb), which is the internal name of a Control. Please refer to the source for details on methods and instance variables.
When your mixin method is called, `self` will be an instance of an anonymous class representing the control being executed; each control gets its own anonymous class. The parent class of the anonymous class will be [Inspec::Rule](https://github.com/inspec/inspec/blob/main/lib/inspec/rule.rb), which is the internal name of a Control. Please refer to the source for details on methods and instance variables.
#### Describe DSL Context

2
examples/plugins/inspec-resource-lister/README.md
View file

@ -46,7 +46,7 @@ You are encouraged to use this plugin as a starting point for real plugins.
## Development of a Plugin
[Plugin Development](https://github.com/inspec/inspec/blob/master/docs/dev/plugins.md) is documented on the `inspec` project on GitHub. Additionally, this example
[Plugin Development](https://github.com/inspec/inspec/blob/main/docs/dev/plugins.md) is documented on the `inspec` project on GitHub. Additionally, this example
plugin has extensive comments explaining what is happening, and why.
### A Tour of the Plugin

2
examples/plugins/inspec-resource-lister/inspec-resource-lister.gemspec
View file

@ -19,7 +19,7 @@ Gem::Specification.new do |spec|
spec.email = ["cwolfe@chef.io"]
spec.summary = "InSpec Plugin example, lists available resources"
spec.description = "Example for implementing an InSpec Plugin. This simply lists available resources."
spec.homepage = "https://github.com/inspec/inspec/tree/master/examples/plugin"
spec.homepage = "https://github.com/inspec/inspec/tree/main/examples/plugin"
spec.license = "Apache-2.0"
# Though complicated-looking, this is pretty standard for a gemspec.

2
examples/plugins/inspec-resource-lister/test/fixtures/README.md vendored
View file

@ -19,6 +19,6 @@ When writing your functional tests, you can point InSpec at the various test fix
## Using test fixtures provided with core inspec
InSpec itself ships with many test fixtures - not just profiles, but attribute files, configuration directories, and more. Examine them at [the fixtures directory](https://github.com/inspec/inspec/tree/master/test/fixtures)
InSpec itself ships with many test fixtures - not just profiles, but attribute files, configuration directories, and more. Examine them at [the fixtures directory](https://github.com/inspec/inspec/tree/main/test/fixtures)
To use them, see the helper.rb file included in the example at test/helper.rb .

2
inspec-bin/inspec-bin.gemspec
View file

@ -9,7 +9,7 @@ Gem::Specification.new do |spec|
spec.email = ["inspec@chef.io"]
spec.summary = "Infrastructure and compliance testing."
spec.description = "InSpec executable for inspec gem. Use of this executable may require accepting a license agreement."
spec.homepage = "https://github.com/inspec/inspec/tree/master/inspec-bin"
spec.homepage = "https://github.com/inspec/inspec/tree/main/inspec-bin"
spec.license = "Apache-2.0"
spec.require_paths = ["lib"]

2
inspec-bin/inspec-core-bin.gemspec
View file

@ -12,7 +12,7 @@ Gem::Specification.new do |spec|
spec.email = ["inspec@chef.io"]
spec.summary = "Infrastructure and compliance testing."
spec.description = "InSpec executable for inspec-core gem. Use of this executable may require accepting a license agreement."
spec.homepage = "https://github.com/inspec/inspec/tree/master/inspec-bin"
spec.homepage = "https://github.com/inspec/inspec/tree/main/inspec-bin"
spec.license = "Apache-2.0"
spec.require_paths = ["lib"]

2
lib/plugins/inspec-init/templates/plugins/inspec-plugin-template/test/fixtures/README.md vendored
View file

@ -19,6 +19,6 @@ When writing your functional tests, you can point InSpec at the various test fix
## Using test fixtures provided with the `inspec` source code
InSpec itself ships with many test fixtures - not just profiles, but attribute files, configuration directories, and more. Examine them at [the fixtures directory](https://github.com/inspec/inspec/tree/master/test/fixtures)
InSpec itself ships with many test fixtures - not just profiles, but attribute files, configuration directories, and more. Examine them at [the fixtures directory](https://github.com/inspec/inspec/tree/main/test/fixtures)
To use them, see the helper.rb file included in the example at test/helper.rb .

2
lib/plugins/inspec-reporter-html2/README.md
View file

@ -50,4 +50,4 @@ Specifies the full path to the location of a JavaScript file that will be read a
## Developing This Plugin
This plugin is part of the Chef InSpec source code. While it has its own tests, the general contribution policy is dictated by the Chef InSpec project at https://github.com/inspec/inspec/blob/master/CONTRIBUTING.md
This plugin is part of the Chef InSpec source code. While it has its own tests, the general contribution policy is dictated by the Chef InSpec project at https://github.com/inspec/inspec/blob/main/CONTRIBUTING.md