pdksync 0.5.0 → 0.8.0

Sign up to get free protection for your applications and to get access to all the features.
data/README.md CHANGED
@@ -4,12 +4,13 @@ Table of Contents
4
4
  -----------------
5
5
 
6
6
  1. [Overview](#overview)
7
- 2. [Usage](#usage)
8
- 3. [How it works](#how-it-works)
9
- 4. [Configuration](#configuration)
10
- 5. [Workflow](#workflow)
11
- 6. [Migrating from modulesync to pdksync](#migrating-from-modulesync-to-pdksync)
12
- 7. [Contributing](#contributing)
7
+ 2. [Requirements](#requirements)
8
+ 3. [Usage](#usage)
9
+ 4. [How it works](#how-it-works)
10
+ 5. [Configuration](#configuration)
11
+ 6. [Workflow](#workflow)
12
+ 7. [Migrating from modulesync to pdksync](#migrating-from-modulesync-to-pdksync)
13
+ 8. [Contributing](#contributing)
13
14
 
14
15
  ### Overview
15
16
  --------
@@ -18,10 +19,15 @@ Pdksync is an efficient way to run a `pdk update` command against the various Pu
18
19
 
19
20
  Pdksync by default expects that your Puppet module repositories live on GitHub and will behave accordingly. It also supports GitLab as an alternative Git hosting platform.
20
21
 
22
+ ### Requirements
23
+ --------
24
+ * Ruby >= 2.7
25
+ * Bundler >= 1.15
26
+
21
27
  ### Usage
22
28
  ----------
23
29
 
24
- > Note: This tool creates a 'live' pull (merge) request against the master branch of the module it is running against — defined in `managed_modules.yml`. Before running this tool, ensure this file reflects the modules you wish it to run against. Additionally make sure that the Pdksync configuration file `$HOME/.pdksync.yml` sets the correct namespace, Git platform and Git base URI for your modules. See section [Configuration](#configuration) for details.
30
+ > Note: This tool creates a 'live' pull (merge) request against the main branch of the module it is running against — defined in `managed_modules.yml`. Before running this tool, ensure this file reflects the modules you wish it to run against. Additionally make sure that the Pdksync configuration file `$HOME/.pdksync.yml` sets the correct namespace, Git platform and Git base URI for your modules. See section [Configuration](#configuration) for details.
25
31
 
26
32
  1. To use pdksync, clone the GitHub repo or install it as a gem. Set up the environment by exporting a GitHub token:
27
33
 
@@ -43,6 +49,35 @@ bundle install --path .bundle/gems/
43
49
  bundle exec rake pdksync
44
50
  ```
45
51
 
52
+ ### Github Token Permissions
53
+ ----------
54
+
55
+ Follow the steps below to set up a Github token with the minimum level of permissions required by `pdksync`:
56
+
57
+ - Log in to your Github account and navigate to the [Personal Access Tokens](https://github.com/settings/tokens) section under `Settings -> Developer settings`
58
+ - Click [`Generate new token`](https://github.com/settings/tokens/new)
59
+ - Select the check boxes appropriate for your use case below
60
+
61
+ #### **Public Repos, No Workflow Modifications Permitted**
62
+
63
+ - [ ] **repo**
64
+ - [ ] repo:status
65
+ - [ ] repo_deployment
66
+ - [x] public_repo
67
+ - [ ] repo:invite
68
+ - [ ] security_events
69
+ - [ ] workflow
70
+
71
+ #### **Private Repos or Public Repos with Workflow Modifications Permitted**
72
+
73
+ - [x] **repo**
74
+ - [x] repo:status
75
+ - [x] repo_deployment
76
+ - [x] public_repo
77
+ - [x] repo:invite
78
+ - [x] security_events
79
+ - [x] workflow
80
+
46
81
  ### How it works
47
82
  ------------
48
83
 
@@ -61,7 +96,7 @@ source "https://rubygems.org"
61
96
 
62
97
  git_source(:github) { |repo_name| "https://github.com/#{repo_name}" }
63
98
 
64
- gem 'pdksync', github: 'puppetlabs/pdksync', ref: 'pdksync-externalisation-fixes'
99
+ gem 'pdksync'
65
100
  gem 'rake'
66
101
  ```
67
102
 
@@ -78,7 +113,7 @@ pdksync.yml:
78
113
  ```yaml
79
114
  ---
80
115
  namespace: 'YOUR GITHUB NAME'
81
- git_base_uri: 'git@github.com:'
116
+ git_base_uri: 'git@github.com'
82
117
  ```
83
118
 
84
119
 
@@ -86,11 +121,66 @@ Run the following commands to check that everything is working as expected:
86
121
 
87
122
  ```shell
88
123
  bundle install --path .bundle/gems/
89
- bundle exec rake -T
90
124
  bundle exec rake git:clone_managed_modules
91
125
  ```
92
126
 
93
- The rake tasks take in a file, `managed_modules.yml`, stored within the local directory that lists all the repositories that need to be updated. It then clones them, one after another, so that a local copy exists. The `pdk update` command is ran against this local copy, with the subsequent changes being added into a commit on a unique branch. It is then pushed back to the remote master where the local copy was originally cloned. A pull request against master is opened, and pdksync begins to clone the next repository.
127
+ pdksync tool is extended with the feature to update the Gemfile. Puppet provides a lot of useful gems to access and manage their functionality between modules. This functionality will help user to perform gem testing prior to release. User is given new rake tasks to update SHA/Version/Branch/line in the Gemfile. Then the changes can be committed, PR can be created which will run the acceptance tests in the PR. If all the tests are executing successfully then the user can close the PRS and release the gem. Below given are the workflows for doing module gem testing with pdksync.
128
+
129
+
130
+ In Workflow 1 we can clone modules, update the gem file, create the commit, push the changes and create the PR using separate rake tasks.
131
+ ```shell
132
+ bundle install --path .bundle/gems/
133
+ bundle exec rake git:clone_managed_modules
134
+ bundle exec rake 'pdksync:gem_file_update[]'
135
+ bundle exec rake 'git:create_commit[]'
136
+ bundle exec rake 'git:push'
137
+ bundle exec rake 'git:create_pr[]'
138
+ ```
139
+
140
+ In Workflow 2 we can clone modules, update the gem file, create the commit, push the changes and create the PR using single rake task
141
+ ```
142
+ Using single rake job
143
+ bundle install --path .bundle/gems/
144
+ bundle exec rake 'gem_testing[]'
145
+ ```
146
+
147
+ In Workflow 3 we can clone modules, update the gem file, run the tests locally for litmus modules without creating commit,pushing or creating the PR
148
+ ```
149
+ Using single rake job
150
+ bundle install --path .bundle/gems/
151
+ bundle exec rake git:clone_managed_modules
152
+ bundle exec rake 'pdksync:gem_file_update[]'
153
+ bundle exec rake 'pdksync:run_tests_locally[]'
154
+ bundle exec rake 'pdksync:fetch_test_results_locally[]'
155
+ ```
156
+
157
+ Once the verified gem is released we can use pdksync to update the the new version of gem released in the .sync.yaml file.
158
+
159
+ pdksync tool is extended with the feature to perform multi gem testing (`puppet-module-gems`). This functionality will identify the current version and bump the version by one. Then it will build and push the gems to gemfury account. Export the GEMFURY_TOKEN to use this rake task.
160
+
161
+ ```shell
162
+ export GEMFURY_TOKEN=<access_token>
163
+ ```
164
+
165
+ Run the following commands to check that everything is working as expected:
166
+
167
+ ```shell
168
+ bundle install --path .bundle/gems/
169
+ bundle exec rake -D
170
+ bundle exec rake 'git:clone_gem['gem_name']'
171
+ ```
172
+ Below given are the workflows for doing multi gem testing with pdksync.
173
+
174
+ In this workflow we can clone gems, update the version, build the gem, push the changes to gemfury and update the gem file of the required modules with the latest gem updated in the fury. Then we can create PR or run tests locally or run tests through jenkins to verify the module test results.
175
+
176
+ ```shell
177
+ bundle install --path .bundle/gems/
178
+ bundle exec rake 'git:clone_gem[]'
179
+ bundle exec rake 'pdksync:multi_gem_testing[]'
180
+ bundle exec rake 'pdksync:multigem_file_update[]'
181
+ ```
182
+
183
+ The rake tasks take in a file, `managed_modules.yml`, stored within the local directory that lists all the repositories that need to be updated. It then clones them, one after another, so that a local copy exists. The `pdk update` command is ran against this local copy, with the subsequent changes being added into a commit on a unique branch. It is then pushed back to the remote origin — where the local copy was originally cloned. A pull request against main is opened, and pdksync begins to clone the next repository.
94
184
 
95
185
  By default, pdksync will supply a label to a PR (default is 'maintenance'). This can be changed by creating `pdksync.yml` in the local directory and setting the `pdksync_label` key. You must ensure that the label selected exists on the modules that you are applying pdksync to. Should you wish to disable this feature, set `pdksync_label` to an empty string i.e. `''`. Similarly, when supplying a label using the `git:create_pr` rake task, the label must exist on each of the managed modules to run successfully.
96
186
 
@@ -104,9 +194,163 @@ The following rake tasks are available with pdksync:
104
194
  - `pdksync:pdk_convert` Runs PDK convert against modules.
105
195
  - `pdksync:pdk_validate` Runs PDK validate against modules.
106
196
  - `pdksync[:additional_title]` Run full pdksync process, clone repository, pdk update, create pr. Additional information can be added to the title, which will be appended before the reference section.
107
- - `rake pdksync` PR title outputs as `pdksync - pdksync_heads/master-0-gabccfb1`
108
- - `rake 'pdksync[MODULES-8231]'` PR title outputs as `pdksync - MODULES-8231 - pdksync_heads/master-0-gabccfb1`
109
- - `pdksync:run_a_command[:command]` Run a command against modules eg rake 'pdksync:run_a_command[complex command here -f -gx]'
197
+ - `rake pdksync` PR title outputs as `pdksync - pdksync_heads/main-0-gabccfb1`
198
+ - `rake 'pdksync[MODULES-8231]'` PR title outputs as `pdksync - MODULES-8231 - pdksync_heads/main-0-gabccfb1`
199
+ - `pdksync:run_a_command[:command, :option]` Run a command against modules eg rake 'pdksync:run_a_command[complex command here -f -gx, 'background']'. :option is an optional parameter which states to run command in backgroud.
200
+ - `pdksync:gem_file_update[[:gem_to_test, :gem_line, :gem_sha_finder, :gem_sha_replacer, :gem_version_finder, :gem_version_replacer, :gem_branch_finder, :gem_branch_replacer]]` Run gem_file_update against modules
201
+ - eg rake to update gem line `pdksync:gem_file_update['puppet_litmus', "gem 'puppet_litmus'\, git: 'https://github.com/test/puppet_litmus.git'\, branch: 'testbranch'"]'`
202
+ - eg rake to update sha `pdksync:gem_file_update['puppet_litmus', '', '20ee04ba1234e9e83eb2ffb5056e23d641c7a018', '20ee04ba1234e9e83eb2ffb5056e23d641c7a31']`
203
+ - eg rake to update version`pdksync:gem_file_update['puppet_litmus', '', '', '', "= 0.9.0", "<= 0.10.0", '', '']`
204
+ - eg rake to update branch `pdksync:gem_file_update['puppet_litmus', '', '', '', '', '', 'testbranch', 'testbranches']`
205
+ - `rake 'gem_testing[:additional_title, :gem_to_test, :gem_line, :gem_sha_finder, :gem_sha_replacer, :gem_version_finder, :gem_version_replacer, :gem_branch_finder, :gem_branch_replacer]'` Run complete Gem file testing (cloning, gemfileupdate, create commit, create PR)PR title outputs as `pdksync_gemtesting - MODULES-8231 - pdksync_heads/main-0-gabccfb1`
206
+ - eg rake to perform gem file testing `gem_testing['MODULES-testing', 'puppet_litmus', '', '20ee04ba1234e9e83eb2ffb5056e23d641c7a018', 'testsha']`
207
+ - `pdksync:run_tests_locally[:provision_type, :puppet_collection]` Run litmus modules locally
208
+ - eg rake 'pdksync:run_tests_locally["default"]'
209
+ - `pdksync:fetch_test_results_locally[]` Fetch litmus modules local run results
210
+ - eg rake 'pdksync:fetch_test_results_locally[]'
211
+ - `pdksync:run_tests_jenkins[:jenkins_server_url, :github_branch, :test_framework, :github_user]` Run traditional modules on jenkins. For now this rake task works just for test_framework: jenkins.
212
+ - eg rake 'pdksync:run_tests_jenkins[test_branch, '', test_user]'
213
+ - `pdksync:test_results_jenkins[]` Fetch traditional modules jenkins run results
214
+ - eg rake 'pdksync:test_results_jenkins[jenkins_server_url]'
215
+ - `git:clone_gem[:gem_name]` Clone gem.
216
+ - `pdksync:multi_gem_testing[:gem_name, :version_file, :build_gem, :gem_path, :gemfury_username]` Build and Push new gems built to the gemfury account for testing eg rake 'pdksync:multi_gem_testing[]'
217
+ - `pdksync:multigem_file_update[:gem_name, :gemfury_username]` Update Gemfile of the modules with the new gem should be pushed to Gemfury.'
218
+ - `pdksync:add_provision_list[:key, :provisioner, :images]` Add a provision list key to provision.yaml.
219
+ - `pdksync:generate_vmpooler_release_checks[:puppet_version]` Generates release checks in provision.yaml based on module compatible platforms and puppet version
220
+ - `pdksync:add_platform_to_metadata[:os, :version]` Add a given OS Version to the metadata
221
+ - `pdksync:remove_platform_from_metadata[:os, :version]` Remove a given OS Version from the metadata
222
+
223
+
224
+ You can run ```bundle exec rake -D``` to view the list of available rake tasks.
225
+
226
+ ### Adding/Updating `provision.yaml`
227
+ To add/update an entry in the `provision.yaml`, run the following task:
228
+ ```ruby
229
+ bundle exec rake pdksync:add_provision_list[:key, :provisioner, :images]
230
+ ```
231
+ The `:images` parameter is a variable in length - everything from the 3rd arg onwards, separated by commas, will be treated as an image.
232
+ For example:
233
+ ```ruby
234
+ bundle exec rake "pdksync:add_provision_list[release_checks_latest_os, abs, 'redhat-8-x86_64', 'centos-8-x86_64', 'debian-10-x86_64', 'sles-15-x86_64', 'ubuntu-2004-x86_64', 'win-2019-core-x86_64', 'win-10-pro-x86_64']"
235
+ ```
236
+ This will create a new entry (or update an existing entry, if it already exists) in the `provision.yaml`:
237
+ ```yaml
238
+ release_checks_latest_os:
239
+ provisioner: abs
240
+ images:
241
+ - redhat-8-x86_64
242
+ - centos-8-x86_64
243
+ - debian-10-x86_64
244
+ - sles-15-x86_64
245
+ - ubuntu-2004-x86_64
246
+ - win-2019-core-x86_64
247
+ - win-10-pro-x86_64
248
+ ```
249
+
250
+ ### Generating Release Checks Config in `provision.yaml` for Given Puppet Version
251
+ To generate a release checks configuration that will use VMPooler (via the ABS provisioner) in the `provision.yaml` that satisfies both:
252
+ - The supported platforms of the given Puppet version
253
+ - The supported platforms of the module
254
+
255
+ ...you can run:
256
+ ```ruby
257
+ pdksync:generate_vmpooler_release_checks[:puppet_version]
258
+ ```
259
+
260
+ #### Step 1: Create Puppet version supported platform config entry
261
+ Ensure that the there is an entry in the `lib/pdksync/conf/puppet_abs_support_platforms.yaml` config for the Puppet version you wish to add an entry for:
262
+ ```yaml
263
+ 7:
264
+ centos: ['7', '8']
265
+ debian: ['9', '10']
266
+ oracle: ['7']
267
+ redhat: ['7', '8']
268
+ sles: ['12', '15']
269
+ scientific: ['7']
270
+ ubuntu: ['18.04', '20.04']
271
+ win: ['2012r2', '2016-core', '2019-core', '10']
272
+ ```
273
+ **NOTE: Please be aware of the requirements regarding the platform naming and version syntax. Instructions and an explanation are within the `puppet_support_platforms.yaml`**
274
+
275
+ The platforms specified above do not necessarily have to reflect ALL the platforms that Puppet version supports - this is the configuration we wish to test against.
276
+ If you do not wish to test against `solaris` then simply omit it from the above config.
277
+
278
+ #### Step 2: Add the config entries to `provision.yaml`
279
+ Say you want to add a configuration key for Puppet 7 (_and you have ensured the `puppet_support_platforms.yaml` is correct as defined in the step above_), you would run:
280
+ ```ruby
281
+ bundle exec rake 'pdksync:generate_vmpooler_release_checks[7]'
282
+ ```
283
+ This will create a `release_checks_7` entry in the `provision.yaml` of the managed modules cloned down that contains a list of appropriate number of platforms to satisfy the conditions outlined above.
284
+
285
+ ### Adding a new platform to `metadata.json`
286
+
287
+ To add a new OS or OS version to the `operatingsystem_support` key in the `metadata.json`:
288
+
289
+ ```ruby
290
+ bundle exec rake 'pdksync:add_platform_to_metadata[:os, :version]'
291
+ ```
292
+
293
+ For example, to add a new OS called 'FooBar OS' and versions `1`, `2` and `3`:
294
+
295
+ ```ruby
296
+ bundle exec rake 'pdksync:add_platform_to_metadata[FooBar,1]'
297
+ bundle exec rake 'pdksync:add_platform_to_metadata[FooBar,2]'
298
+ bundle exec rake 'pdksync:add_platform_to_metadata[FooBar,3]'
299
+ ```
300
+
301
+ To add a new version (e.g. `22.04`) to an existing entry (e.g. `Ubuntu`):
302
+
303
+ ```ruby
304
+ bundle exec rake 'pdksync:add_platform_to_metadata[Ubuntu,22.04]'
305
+ ```
306
+
307
+ **PLEASE NOTE: All OS names are normalised to the conventions defined in the `normalize_os` method - see below for more details.**
308
+
309
+ ### Removing a platform from `metadata.json`
310
+
311
+ To remove a platform version from `metadata.json`:
312
+
313
+ ```ruby
314
+ bundle exec rake 'pdksync:remove_platform_from_metadata[:os, :version]'
315
+ ```
316
+
317
+ **PLEASE NOTE: There is currently a limitation on removing an entire OS if no versions are specified - feel free to enhance with a PR :)**
318
+
319
+ For example, to remove version `14.04` from `Ubuntu`:
320
+
321
+ ```ruby
322
+ bundle exec rake 'pdksync:remove_platform_from_metadata[Ubuntu,14.04]'
323
+ ```
324
+
325
+ ### Update requirements
326
+
327
+ To add / modify a requirement from the `requirements` key of the `metadata.json`:
328
+
329
+ ```ruby
330
+ bundle exec rake 'pdksync:update_requirements[:name, :key, :value]'
331
+ ```
332
+
333
+ **PLEASE NOTE: There is currently a limitation on removing an entire requirement entry - feel free to enhance with a PR :)**
334
+
335
+ To update the `puppet` `version_requirement` requirement to `>= 6.0.0 < 8.0.0`:
336
+
337
+ ```ruby
338
+ bundle exec rake 'pdksync:update_requirements[puppet,version_requirement,>= 6.0.0 < 8.0.0]'
339
+ ```
340
+
341
+ To add a new requirement called `foobar` with a parameter called `baz` which has a value of `123`:
342
+
343
+ ```ruby
344
+ bundle exec rake 'pdksync:update_requirements[foobar,baz,123]'
345
+ ```
346
+
347
+ ### Normalize Supported Platforms
348
+
349
+ To normalize the platforms and versions (Windows only) defined in the `operatingsystem_support` key of the `metadata.json` based on [these rules](https://github.com/puppetlabs/pdksync/blob/ebb84d81d2c15115f896995043eac6d666a114a0/lib/pdksync/utils.rb#L1043-L1098):
350
+
351
+ ```ruby
352
+ bundle exec rake 'pdksync:normalize_metadata_supported_platforms'
353
+ ```
110
354
 
111
355
  ### Configuration
112
356
 
@@ -115,8 +359,9 @@ By default pdksync will use hardcoded values for configuring itself. However, if
115
359
  ---
116
360
  namespace: 'puppetlabs'
117
361
  pdksync_dir: 'modules_pdksync'
362
+ pdksync_gem_dir: 'gems_pdksync',
118
363
  push_file_destination: 'origin'
119
- create_pr_against: 'master'
364
+ create_pr_against: 'main'
120
365
  managed_modules: 'managed_modules.yml'
121
366
  pdksync_label: 'maintenance'
122
367
  git_platform: :github
@@ -134,8 +379,14 @@ By default pdksync assumes you are hosting your Puppet modules on GitHub, and Gi
134
379
  Pdksync also supports the GitLab platform, but without official support by Puppetlabs.
135
380
 
136
381
  ##### GitHub
382
+ Github.com and Github enterprise both work with octokit which is used in pdksync. There are some settings
383
+ you will need to adjust if using the on premise github enterprise edition.
137
384
 
138
- To use GitHub you only need to export your GitHub access token as the
385
+ 1. `api_endpoint: https://mygithub.mycompany.com/api/v3`
386
+ 2. `git_base_uri: git@mygithub.mycompany.com`
387
+ 3. `export GITHUB_TOKEN=k3939isdiasdf93i_` (your token goes here)
388
+
389
+ To use GitHub.com you only need to export your GitHub access token as the
139
390
  environment variable `GITHUB_TOKEN` and configure the namespace in which your
140
391
  modules are hosted in `$HOME/.pdksync.yml` as described above.
141
392
 
@@ -163,7 +414,7 @@ export GITLAB_TOKEN=<your GitLab access token here>
163
414
 
164
415
  If you are running your own GitLab instance on premise or use a GitLab instance
165
416
  other than the official one at `https://gitlab.com` you also need to configure
166
- `git_base_uri` and `gitlab_api_endpoint` in `$HOME/.pdksync.yml` so that
417
+ `git_base_uri` and `api_endpoint` in `$HOME/.pdksync.yml` so that
167
418
  pdksync knows from where to clone your modules and where to access to GitLab
168
419
  API to create the live merge requests:
169
420
 
@@ -175,9 +426,70 @@ git_platform: :gitlab
175
426
  git_base_uri: 'https://gitlab.example.com'
176
427
  # alternatively use SSH:
177
428
  #git_base_uri: 'ssh://git@gitlab.example.com:2222'
178
- gitlab_api_endpoint: 'https://gitlab.example.com/api/v4'
429
+ api_endpoint: 'https://gitlab.example.com/api/v4'
430
+ ```
431
+
432
+ ### Setting who has the authoritive
433
+ It may be desirable to allow modules to dictate which version of the pdk-templates they should sync with.
434
+ There are a few settings you can tune to allow for this kind of flexability. These settings are in the pdksync.yml file. All of these settings are optional and have sane defaults. See `rake pdksync:show_config` for the settings that will be used.
435
+
436
+ - pdk_templates_prefix: 'nwops-' (example only, keep as empty string)
437
+ - pdk_templates_ref: 1.12.0
438
+ - pdk_templates_url: https://github.com/puppetlabs/pdk-templates.git
439
+ - module_is_authoritive: true
440
+
441
+ The first setting is `module_is_authoritive`. When this is set to true the templates and ref specified in the metadata become the authoritive source for these settings. Even if you have pdk_templates_ref and pdk_templates_url specified in pdksync.yml the metadata settings will alwasys be used.
442
+
443
+ ```json
444
+ # module/metadata.json
445
+ {
446
+ "pdk-version": "1.11.1",
447
+ "template-url": "https://github.com/puppetlabs/pdk-templates#main",
448
+ "template-ref": "heads/main-0-gb096033"
449
+ }
450
+
179
451
  ```
180
452
 
453
+ When `module_is_authoritive` is set to false the pdk_templates_ref and pdk_templates_url will override what is found in the modules's metadata.json file. This is very useful when you have to control pdk-template upgrades on modules.
454
+
455
+ The other settings dictiate where the templates are located and which branch, tag or reference you want to use.
456
+ `pdk_templates_ref: 'main'` and `pdk_templates_url: https://github.com/puppetlabs/pdk-templates.git`. These settings will only be utilized if module_is_authoritive is set to false. However, if you are performing a conversion via pdksync these settings will also be used since the metadata in the module being converted doesn't have pdk settings yet.
457
+
458
+ The last setting `pdk_templates_prefix` is a special use case that allows folks with internal forks of pdk-templates to keep branches of the pdk-template tags with additional custom changes. Setting this to an empty string disables this. You will most likely need to resolve conflicts with this workflow, so it is not for everyone. If you know of a better way please submmit a pull request.
459
+
460
+ This strategy works in conjunction with the pdk-template git tags and the workflow looks like:
461
+ 1. git fetch upstream (github.com/puppetlabs/pdk-templates)
462
+ 2. git checkout main && git rebase upstream/main
463
+ 3. git checkout -b nwops-1.0.13 nwops-1.0.12
464
+ 4. git rebase 1.0.13
465
+ 5. git push origin nwops-1.0.13
466
+
467
+
468
+ ### Supporting multiple namespaces
469
+ If you have multiple namespaces that you need to support you will need to create a pdksync.yml config
470
+ file for each namespace. This will allow you to create a folder structure and keep a separate
471
+ managed_modules.yml for that namespace too.
472
+
473
+ You can set a PDKSYNC_CONFIG_PATH environment variable that points to the specific pdksync.yml config file for use in a CI or on the CLI. This allows you to set custom names for pdksync.yml file.
474
+
475
+ example: `PDKSYNC_CONFIG_PATH=pdksync_ops.yml`
476
+
477
+ Or you can set a different HOME environment variable that tells pdksync where to find the pdksync.yml file. Pdksync will locate the pdksync.yml file in the HOME folder you specify. The config file name is not changable in this case.
478
+
479
+ example: `HOME=ops`
480
+
481
+ ### Logging output
482
+ Pdksync uses a logger class to log all output. You can control how the logger works via a few environment variables.
483
+
484
+ To control the level set the `LOG_LEVEL` to one of
485
+ 1. info
486
+ 2. debug
487
+ 3. fatal
488
+ 4. error
489
+ 5. warn
490
+
491
+ To control where the logs are sent (defaults to stdout) set the `PDKSYNC_LOG_FILENAME` to a file path.
492
+
181
493
  ### Workflow
182
494
  --------
183
495
 
data/Rakefile CHANGED
@@ -1,33 +1,12 @@
1
- require 'pdksync/rake_tasks'
2
- require 'github_changelog_generator/task'
3
- require 'rubocop/rake_task'
1
+ require "pdksync/rake_tasks"
2
+ require "rubocop/rake_task"
3
+ require "rspec/core/rake_task"
4
+ require "bundler/gem_tasks"
4
5
 
5
6
  RuboCop::RakeTask.new(:rubocop) do |t|
6
- t.options = ['--display-cop-names']
7
+ t.options = ["--display-cop-names"]
7
8
  end
8
9
 
9
- GitHubChangelogGenerator::RakeTask.new :changelog do |config|
10
- config.user = 'puppetlabs'
11
- config.project = 'pdksync'
12
- # config.since_tag = '1.1.1'
13
- config.future_release = '0.5.0'
14
- config.exclude_labels = ['maintenance']
15
- config.header = "# Change log\n\nAll notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) and this project adheres to [Semantic Versioning](http://semver.org)."
16
- config.add_pr_wo_labels = true
17
- config.issues = false
18
- config.merge_prefix = "### UNCATEGORIZED PRS; GO LABEL THEM"
19
- config.configure_sections = {
20
- "Changed" => {
21
- "prefix" => "### Changed",
22
- "labels" => ["backwards-incompatible"],
23
- },
24
- "Added" => {
25
- "prefix" => "### Added",
26
- "labels" => ["feature", "enhancement"],
27
- },
28
- "Fixed" => {
29
- "prefix" => "### Fixed",
30
- "labels" => ["bugfix"],
31
- },
32
- }
33
- end
10
+ RSpec::Core::RakeTask.new(:spec)
11
+
12
+ task :default => :spec
@@ -0,0 +1,41 @@
1
+ # PUPPET VERSION PLATFORM COMPATIBILITY
2
+ #
3
+ # Define the Puppet version as a root key, then specify the OS platform(s) and versions(s) that this Puppet version is
4
+ # compatible with AND that you wish to test on. If you wish to exclude a platform from testing, simply omit it.
5
+ #
6
+ # OS names and versions must conform to the VMPooler nomenclature and conventions.
7
+ #
8
+ # Running 'bundle exec rake 'pdksync:generate_vmpooler_release_checks[7]' will generate an entry in the 'provision.yaml'
9
+ # for each managed module that contains a configuration that satisfies both:
10
+ # - The module's compatible platforms
11
+ # - The Puppet version's compatible platforms (in this example: '7')
12
+ #
13
+ # NOTE: arch will always be assumed to be 'x86_64'
14
+ ---
15
+ 5:
16
+ centos: ['5', '6', '7', '8']
17
+ debian: ['8', '9', '10']
18
+ oracle: ['5', '6', '7']
19
+ redhat: ['5', '6', '7', '8']
20
+ sles: ['12', '15']
21
+ scientific: ['6', '7']
22
+ ubuntu: ['14.04', '16.04', '18.04']
23
+ win: ['2008r2', '2012r2', '2016', '2019', '10-pro']
24
+ 6:
25
+ centos: ['5', '6', '7', '8']
26
+ debian: ['8', '9', '10']
27
+ oracle: ['5', '6', '7']
28
+ redhat: ['5', '6', '7', '8']
29
+ sles: ['12', '15']
30
+ scientific: ['6', '7']
31
+ ubuntu: ['14.04', '16.04', '18.04', '20.04']
32
+ win: ['2008r2', '2012r2', '2016', '2019', '10-pro']
33
+ 7:
34
+ centos: ['7', '8']
35
+ debian: ['9', '10']
36
+ oracle: ['7']
37
+ redhat: ['7', '8']
38
+ sles: ['12', '15']
39
+ scientific: ['7']
40
+ ubuntu: ['18.04', '20.04']
41
+ win: ['2012r2', '2016', '2019', '10-pro']
@@ -0,0 +1,155 @@
1
+ require 'yaml'
2
+ require 'pdk/version'
3
+ require 'ostruct'
4
+
5
+ # @summary
6
+ # A class used to contain a set of configuration variables
7
+ # @note
8
+ # Configuration is loaded from `$HOME/.pdksync.yml`. If $HOME is not set, the config_path will use the current directory.
9
+ # The configuration filename and path can be overridden with env variable PDK_CONFIG_PATH
10
+ # Set PDKSYNC_LABEL to '' to disable adding a label during pdksync runs.
11
+ module PdkSync
12
+ class Configuration < OpenStruct
13
+ SUPPORTED_SCM_PLATFORMS = [:github, :gitlab].freeze
14
+ PDKSYNC_FILE_NAME = 'pdksync.yml'.freeze
15
+
16
+ # Any key value added to the default config or custom config
17
+ # will automatically be a new configuration item and referenced
18
+ # via Configuration.new.<key_name> ie.
19
+ # c = Configuration.new
20
+ # c.api_endpoint
21
+ DEFAULT_CONFIG = {
22
+ namespace: 'puppetlabs',
23
+ pdksync_dir: 'modules_pdksync',
24
+ pdksync_gem_dir: 'gems_pdksync',
25
+ push_file_destination: 'origin',
26
+ create_pr_against: 'main',
27
+ managed_modules: 'managed_modules.yml',
28
+ pdksync_label: 'maintenance',
29
+ git_platform: :github,
30
+ git_base_uri: 'https://github.com',
31
+ gitlab_api_endpoint: 'https://gitlab.com/api/v4',
32
+ api_endpoint: nil,
33
+ pdk_templates_prefix: nil,
34
+ pdk_templates_ref: PDK::VERSION,
35
+ pdk_templates_url: 'https://github.com/puppetlabs/pdk-templates.git',
36
+ jenkins_platform: :jenkins,
37
+ jenkins_base_uri: 'https://jenkins.io',
38
+ jenkins_api_endpoint: '',
39
+ jenkins_server_url: '',
40
+ module_is_authoritive: true
41
+ }.freeze
42
+
43
+ # @param config_path [String] - the path to the pdk config file
44
+ def initialize(config_path = ENV['PDKSYNC_CONFIG_PATH'])
45
+ @config_path = locate_config_path(config_path)
46
+ @custom_config = DEFAULT_CONFIG.merge(custom_config(@config_path))
47
+ @custom_config[:pdk_templates_ref] = "#{@custom_config[:pdk_templates_prefix]}#{@custom_config[:pdk_templates_ref]}"
48
+ super(@custom_config)
49
+ valid_scm?(git_platform)
50
+ valid_access_token?
51
+ end
52
+
53
+ # @return [Hash] - returns the access settings for git scm
54
+ def git_platform_access_settings
55
+ @git_platform_access_settings ||= {
56
+ access_token: access_token,
57
+ gitlab_api_endpoint: gitlab_api_endpoint || api_endpoint,
58
+ api_endpoint: api_endpoint
59
+
60
+ }
61
+ end
62
+
63
+ def jenkins_platform_access_settings
64
+ @jenkins_platform_access_settings ||= {
65
+ jenkins_username: ENV['JENKINS_USERNAME'].freeze,
66
+ jenkins_password: ENV['JENKINS_PASSWORD'].freeze,
67
+ jenkins_api_endpoint: ''
68
+ }
69
+ end
70
+
71
+ # @return [Hash] - returns the access settings for gemfury account
72
+ def gemfury_access_settings
73
+ valid_access_token_gem_fury?
74
+ @gemfury_access_token = access_token_gem_fury
75
+ end
76
+
77
+ # @return [String] return a rendered string for pdk to use the templates
78
+ def templates
79
+ "--template-url=#{pdk_templates_url} --template-ref=#{pdk_templates_ref}"
80
+ end
81
+
82
+ # @param path [String] path to the pdksync config file in yaml format
83
+ # @return [Hash] the custom configuration as a hash
84
+ def custom_config(path = nil)
85
+ return {} unless path
86
+ return {} unless File.exist?(path)
87
+ c = (YAML.load_file(path) || {}).transform_keys_to_symbols
88
+ c[:git_base_uri] ||= 'https://gitlab.com' if c[:git_platform].eql?(:gitlab)
89
+ c
90
+ end
91
+
92
+ # @return [String] the path the pdksync config file, nil if not found
93
+ def locate_config_path(custom_file = nil)
94
+ files = [
95
+ custom_file,
96
+ PDKSYNC_FILE_NAME,
97
+ File.join(ENV['HOME'], PDKSYNC_FILE_NAME)
98
+ ]
99
+ files.find { |file| file && File.exist?(file) }
100
+ end
101
+
102
+ private
103
+
104
+ # @return [Boolean] true if the supported platforms were specified correctly
105
+ # @param scm [Symbol] - the scm type (:github or :gitlab)
106
+ def valid_scm?(scm)
107
+ unless SUPPORTED_SCM_PLATFORMS.include?(scm)
108
+ raise ArgumentError, "Unsupported Git hosting platform '#{scm}'."\
109
+ " Supported platforms are: #{SUPPORTED_SCM_PLATFORMS.join(', ')}"
110
+ end
111
+ true
112
+ end
113
+
114
+ # @return [Boolean] true if the access token for the scm platform was supplied
115
+ def valid_access_token?
116
+ if access_token.nil?
117
+ raise ArgumentError, "Git platform access token for #{git_platform.capitalize} not set"\
118
+ " - use 'export #{git_platform.upcase}_TOKEN=\"<your token>\"' to set"
119
+ end
120
+ true
121
+ end
122
+
123
+ # @return [Boolean] true if the access token for the gemfury was supplied
124
+ def valid_access_token_gem_fury?
125
+ if access_token_gem_fury.nil?
126
+ raise 'Gemfury access token not set'\
127
+ " - use 'export GEMFURY_TOKEN=\"<your token>\"' to set"
128
+ end
129
+ true
130
+ end
131
+
132
+ # @return [String] the platform specific access token
133
+ def access_token
134
+ case git_platform
135
+ when :github
136
+ ENV['GITHUB_TOKEN'].freeze
137
+ when :gitlab
138
+ ENV['GITLAB_TOKEN'].freeze
139
+ end
140
+ end
141
+
142
+ # @return [String] the gem_fury access token
143
+ def access_token_gem_fury
144
+ ENV['GEMFURY_TOKEN'].freeze
145
+ end
146
+ end
147
+ end
148
+
149
+ # monkey patch
150
+ class Hash
151
+ # take keys of hash and transform those to a symbols
152
+ def transform_keys_to_symbols
153
+ each_with_object({}) { |(k, v), memo| memo[k.to_sym] = v; }
154
+ end
155
+ end