mirror/stackexchange-dnscontrol
1
0
Fork 0
mirror of https://github.com/StackExchange/dnscontrol.git synced 2024-05-11 05:55:12 +00:00
Code Issues Releases Activity

CHORE: Remove references to old CircleCI build system (#2333)

Browse Source 
Co-authored-by: Tom Limoncelli <tal@whatexit.org>
This commit is contained in:
Tom Limoncelli
2023-05-08 08:45:21 -04:00
committed by GitHub
parent 5fd8b65815
commit 11c9f805d8
2 changed files with 32 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@ -1,12 +1,10 @@
# DNSControl # DNSControl
[![CircleCI](https://circleci.com/gh/StackExchange/dnscontrol/tree/master.svg?style=svg)](https://circleci.com/gh/StackExchange/dnscontrol/tree/master) [![StackExchange/dnscontrol/build](https://github.com/StackExchange/dnscontrol/actions/workflows/build.yml/badge.svg)](https://github.com/StackExchange/dnscontrol/actions/workflows/build.yml)
[![Gitter chat](https://badges.gitter.im/dnscontrol/Lobby.png)](https://gitter.im/dnscontrol/Lobby) [![Gitter chat](https://badges.gitter.im/dnscontrol/Lobby.png)](https://gitter.im/dnscontrol/Lobby)
[![Google Group](https://img.shields.io/badge/google%20group-chat-green.svg)](https://groups.google.com/forum/#!forum/dnscontrol-discuss) [![Google Group](https://img.shields.io/badge/google%20group-chat-green.svg)](https://groups.google.com/forum/#!forum/dnscontrol-discuss)
[![PkgGoDev](https://pkg.go.dev/badge/github.com/StackExchange/dnscontrol)](https://pkg.go.dev/github.com/StackExchange/dnscontrol/v3) [![PkgGoDev](https://pkg.go.dev/badge/github.com/StackExchange/dnscontrol)](https://pkg.go.dev/github.com/StackExchange/dnscontrol/v3)
[![CircleCI](https://dl.circleci.com/insights-snapshot/gh/StackExchange/dnscontrol/master/build/badge.svg?window=30d)](https://app.circleci.com/insights/github/StackExchange/dnscontrol/workflows/build/overview?branch=master&reporting-window=last-30-days&insights-snapshot=true)
[DNSControl](https://docs.dnscontrol.org/) is a system [DNSControl](https://docs.dnscontrol.org/) is a system
for maintaining DNS zones. It has two parts: for maintaining DNS zones. It has two parts:
a domain specific language (DSL) for describing DNS zones plus a domain specific language (DSL) for describing DNS zones plus

115
documentation/byo-secrets.md
View File

@ -49,114 +49,61 @@ only run if they have access to the secrets they will need.
# How it works # How it works
Tests are executed if `*_DOMAIN` exists. If the value is empty or Tests are executed if `*_DOMAIN` exists where `*` is the name of the provider. If the value is empty or
unset, the test is skipped. If a test doesn't require secrets, the unset, the test is skipped.
`*_DOMAIN` variable is hardcoded so that it always runs. Otherwise, it is set by looking up For example, if a provider is called `FANCYDNS`, there must
the secret. For example, if a provider is called `FANCYDNS`, there must
be a secret called `FANCYDNS_DOMAIN`. be a secret called `FANCYDNS_DOMAIN`.
# Bring your own secrets # Bring your own secrets
This section describes how to add a provider to the testing system. This section describes how to add a provider to the testing system.
In this example, we will use a fictional DNS provider named
"FANCYDNS".
Step 1: Create a branch Step 1: Create a branch
Create a branch as you normally would to submit a PR to the project. Create a branch as you normally would to submit a PR to the project.
Step 2: Update `build.yml` Step 2: Update `build.yml`
In this branch, edit `.circleci/config.yml`: In this branch, edit `.github/workflows/build.yml`:
1. In the `integration-tests` section, add the name of your provider 1. In the `integration-test-providers` section, the name of the provider.
to the matrix of providers. Technically you are adding to the list
at `workflows.build.jobs.integration-tests.matrix.parameters.provider`.
{% code title=".circleci/config.yml" %} Add your provider's name (alphabetically).
```diff The line looks something like:
matrix:
provider:
- DIGITALOCEAN
+ - FANCYDNS
- GANDI_V5
- INWX
```
{% endcode %}
2. Add your test's env: {% code title=".github/workflows/build.yml" %}
Also in `.circleci/config.yml`, locate the env section (technically `jobs.build.integration-tests.environment`) and
add any env variables that should be set by the project, not by an individual. Usually there is none.
Please replicate the formatting of the existing entries:
* A blank comment separates each provider's section.
* The providers are listed in the same order as the matrix.provider list.
* The `*_DOMAIN` variable is first.
* The remaining variables are sorted lexicographically (what nerds call alphabetical order).
```yaml
FANCYDNS_THING: myvalue
``` ```
PROVIDERS: "['BIND','HEXONET','AZURE_DNS','CLOUDFLAREAPI','GCLOUD','NAMEDOTCOM','ROUTE53','CLOUDNS','DIGITALOCEAN','GANDI_V5','HEDNS','INWX','NS1','POWERDNS','TRANSIP']"
# Examples
Let's look at three examples:
## Example 1
The `BIND` integration tests do not require any secrets because it
simply generates files locally.
```yaml
BIND_DOMAIN: example.com
``` ```
{% endcode %}
The existence of `BIND_DOMAIN`, and the fact that the value is 2. Add your providers `_DOMAIN` env variable:
available to all, means these tests will run for everyone.
## Example 2 Add it to the `env` section of `integrtests-diff1` and again in `integrtests-diff2`.
The `AZURE_DNS` provider requires many settings. Since For example, the entry for BIND looks like:
`AZURE_DNS_DOMAIN` comes from GHA's secrets storage, we can be assured
that the tests will skip if the PR does not have access to the
secrets.
If you have a fork and want to automate the testing of `AZURE_DNS`, {% code title=".github/workflows/build.yml" %}
simply set the secrets named in `.circleci/config.yml` and the tests will
activate for your PRs.
Note that `AZURE_DNS_RESOURCE_GROUP` is hardcoded to `DNSControl`. If
this is not true for you, please feel free to submit a PR that turns
it into a variable.
```yaml
AZURE_DNS_RESOURCE_GROUP: DNSControl
``` ```
BIND_DOMAIN: ${{ vars.BIND_DOMAIN }}
## Example 3
The HEXONET integration tests require secrets, but HEXONET provides an
Operational Test and Evaluation (OT&E) environment with some "fake"
credentials which are known publicly.
Therefore, since there's nothing secret about these particular
secrets, we hard-code them into the `build.yml` file. Since
`HEXONET_DOMAIN` does not come from secret storage, everyone can run
these tests. (We are grateful to HEXONET for this public service!)
```yaml
HEXONET_DOMAIN: yodream.com
HEXONET_ENTITY: OTE
HEXONET_PW: test.passw0rd
HEXONET_UID: test.user
``` ```
{% endcode %}
3. Add your providers other ENV variables:
If there are other env variables (for example, for an API key), add that as a "secret".
For example, the entry for CLOUDFLAREAPI looks like this:
{% code title=".github/workflows/build.yml" %}
```
CLOUDFLAREAPI_ACCOUNTID: ${{ secrets.CLOUDFLAREAPI_ACCOUNTID }}
CLOUDFLAREAPI_TOKEN: ${{ secrets.CLOUDFLAREAPI_TOKEN }}
```
{% endcode %}
Step 3. Submit this PR like any other.
{% hint style="info" %}
**NOTE**: The above credentials are [known to the public](providers/hexonet.md).
{% endhint %}
# Caveats # Caveats