You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create a directory for your new indicator by making a copy of `_template_r` or `_template_python` depending on the programming language you intend to use. If using Python, add the name of the directory to the list found in `jobs > build > strategy > matrix > packages` in `.github/workflows/python-ci.yml`, which will enable automated checks for your indicator when you make PRs. The template copies of `README.md` and `REVIEW.md` include the minimum requirements for code structure, documentation, linting, testing, and method of configuration. Beyond that, we don't have any established restrictions on implementation; you can look at other existing indicators see some examples of code layout, organization, and general approach.
54
54
55
-
- Consult your peers with questions! :handshake:
55
+
* Consult your peers with questions! :handshake:
56
56
57
57
Once you have something that runs locally and passes tests you set up your remote branch eventual review and production deployment.
58
58
@@ -75,9 +75,9 @@ becomes available to the public.
75
75
76
76
Once you have your branch set up you should get in touch with a platform engineer to pair up on the remaining production needs. These include:
77
77
78
-
- Adding the necessary Jenkins scripts for your indicator.
79
-
- Preparing the runtime host with any Automation configuration necessities.
80
-
- Reviewing the workflow to make sure it meets the general guidelines and will run as expected on the runtime host.
78
+
* Adding the necessary Jenkins scripts for your indicator.
79
+
* Preparing the runtime host with any Automation configuration necessities.
80
+
* Reviewing the workflow to make sure it meets the general guidelines and will run as expected on the runtime host.
81
81
82
82
Once all the last mile configuration is in place you can create a pull request against `prod` to initiate the CI/CD pipeline which will build, test, and package your indicator for deployment.
83
83
@@ -97,11 +97,46 @@ Currently, the production indicators all live and run on the venerable and peren
97
97
98
98
We use a branch-based git workflow coupled with [Jenkins](https://www.jenkins.io/) and [Ansible](https://www.ansible.com/) to build, test, package, and deploy each indicator individually to the runtime host.
99
99
100
-
- Jenkins dutifully manages the whole process for us by executing several "stages" in the context of a [CI/CD pipeline](https://dzone.com/articles/learn-how-to-setup-a-cicd-pipeline-from-scratch). Each stage does something unique, building on the previous stage. The stages are:
101
-
- Environment - Sets up some environment-specific needs that the other stages depend on.
102
-
- Build - Create the Python venv on the Jenkins host.
103
-
- Test - Run linting and unit tests.
104
-
- Package - Tar and gzip the built environment.
105
-
- Deploy - Trigger an Ansible playbook to place the built package onto the runtime host, place any necessary production configuration, and adjust the runtime envirnemnt (if necessary).
100
+
* Jenkins dutifully manages the whole process for us by executing several "stages" in the context of a [CI/CD pipeline](https://dzone.com/articles/learn-how-to-setup-a-cicd-pipeline-from-scratch). Each stage does something unique, building on the previous stage. The stages are:
101
+
* Environment - Sets up some environment-specific needs that the other stages depend on.
102
+
* Build - Create the Python venv on the Jenkins host.
103
+
* Test - Run linting and unit tests.
104
+
* Package - Tar and gzip the built environment.
105
+
* Deploy - Trigger an Ansible playbook to place the built package onto the runtime host, place any necessary production configuration, and adjust the runtime envirnemnt (if necessary).
106
106
107
107
There are several additional Jenkins-specific files that will need to be created for each indicator, as well as some configuration additions to the runtime host. It will be important to pair with a platform engineer to prepare the necessary production environment needs, test the workflow, validate on production, and ultimately sign off on a production release.
108
+
109
+
### Preparing container images of indicators
110
+
111
+
It may be desirable to build a container image from an indicator. To do this:
112
+
113
+
* Edit the `.github/workflows/build-container-images.yml` file and add your indicator directory name to the `matrix.packages` section of the `jobs:` block:
114
+
115
+
```yaml
116
+
...
117
+
jobs:
118
+
build:
119
+
runs-on: ubuntu-latest
120
+
strategy:
121
+
matrix:
122
+
packages: [ new_indicator ] # indicator directory name
123
+
...
124
+
```
125
+
126
+
* Create a suitable Dockerfile in the root of your indicator directory.
127
+
128
+
* GitHub Actions will try to build this for you and register it in our private repo.
129
+
130
+
Currently we will build container images off of `main` and `prod` branches. These can be pulled by systems or humans that have access to the registry.
0 commit comments