Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds basic workflow for pdk based modules #15

Open
wants to merge 2 commits into
base: v1
Choose a base branch
from

Conversation

logicminds
Copy link

This provides a basic gha workflow for people using pdk. I don't know if this is the correct spot for this workflow but thought I would add in case others want to reference or use.

I am a bit new to gha so this is missing a matrix and extra inputs for further configuration. I don't know if configuration is necessary except for disabling jobs to save on resources.

The docker image puppet/puppet-dev-tools:2022-03-28-92c7176 is the minimum required to make all this work and I don't suggest that the pdk image be used since it is not maintained.

Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have an example repository to test this on? I often use https://github.com/voxpupuli/puppet-example (also for modulesyncs) Perhaps it's better to create a puppet-example-pdk for it.

.github/workflows/pdk-basic.yml Outdated Show resolved Hide resolved
validate:
# The type of runner that the job will run on
runs-on: ubuntu-latest
container: puppet/puppet-dev-tools:2022-03-28-92c7176
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can make this an input so it's only defined once and then callers can override it easily.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome. Only thing I can't do is allow user to pass in matrix. Not sure if people want to support 5,6,7 and also need to control when pdk stops supporting 5.

@logicminds
Copy link
Author

Here is an example: https://github.com/nwops/kontrol-repo-yaml/actions

Note this is for my control repo but it would be the same for component modules too (except ra10ke jobs).

I am thinking this might have to be a separate repo if it should be reusable as an action rather than a workflow.

runs-on: ubuntu-latest
strategy:
matrix:
puppet-version: [5, 6, 7]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have https://github.com/voxpupuli/gha-puppet/blob/v1/.github/workflows/basic.yml#L55-L57 that gets all major puppet versions from the metadata.json and build the matrix dynamically. I'm wondering if this could be ported to here and if it would be worth the effort.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is neat tool. However, that won't work at the enterprise level where metadata is unreliable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're going to specify it somewhere, why not encourage people to do it in metadata.json rather than in workflow.yaml?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am going to update the workflow to use the suggested method. My only concern is that metadata doesn't really support future versions of puppet. So if a modules is only compatible with puppet 6,7 how do we test for 8 before the metadata is updated to 8?

I also filed: puppetlabs/puppet-dev-tools#113 to add puppet-metadata

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if a modules is only compatible with puppet 6,7 how do we test for 8 before the metadata is updated to 8?

It should handle that well since it iterates the major versions range:
https://github.com/voxpupuli/puppet_metadata/blob/bda0b0f62782492f2f8d5d3392e8aa6d02faff72/lib/puppet_metadata/metadata.rb#L138-L151

As you can see there, it doesn't handle the unbounded dependency automatically. >= 7.0 will only be tested on 7 until we change the hardcoded upper limit. I didn't know how to solve that otherwise. In practice I also think it's uncommon.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also how do I handle the case when the user does not have metadata or does not have the puppet version metadata. I don't know if this would occur. Is there a default value that can be supplied or friendly error to update the metadata?

.github/workflows/pdk-basic.yml Outdated Show resolved Hide resolved
.github/workflows/pdk-basic.yml Outdated Show resolved Hide resolved
.github/workflows/pdk-basic.yml Outdated Show resolved Hide resolved
.github/workflows/pdk-basic.yml Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
Copy link
Member

@bastelfreak bastelfreak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me, let's see what @ekohl thinks

Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the README we document every workflow (under https://github.com/voxpupuli/gha-puppet#calling-test-workflows). Please document the PDK example in the same way. That allows (potential) users to discover it's even a feature.

- uses: actions/checkout@v2
- name: action-pdk-validate-puppet-7
run: pdk validate --puppet-version=7
- run: gem install puppet_metadata -N
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In scripts I'd always use the long form

Suggested change
- run: gem install puppet_metadata -N
- run: gem install puppet_metadata --no-document

Comment on lines +240 to +242
run: eval `ssh-agent -s` && ssh-add - <<< '${{ secrets.PRIVATE_SSH_KEY }}'
- name: Puppet
uses: voxpupuli/gha-puppet/.github/workflows/pdk-basic.yml@master
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're missing indenting

Suggested change
run: eval `ssh-agent -s` && ssh-add - <<< '${{ secrets.PRIVATE_SSH_KEY }}'
- name: Puppet
uses: voxpupuli/gha-puppet/.github/workflows/pdk-basic.yml@master
run: eval `ssh-agent -s` && ssh-add - <<< '${{ secrets.PRIVATE_SSH_KEY }}'
- name: Puppet
uses: voxpupuli/gha-puppet/.github/workflows/pdk-basic.yml@master


jobs:
puppet:
- name: Setup deploy key
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it should be a secret that the workflow accepts. Here is where we have an example for the release workflow:

secrets:
username:
description: 'The forge username to use'
required: true
api_key:
description: 'The forge API key'
required: true

(see https://github.com/voxpupuli/gha-puppet#calling-the-release-workflow for how to call it):

Then you can add it as a when: secrets.PRIVATE_SSH_KEY in the workflow and you don't need as much duplication in various workflows.

Comment on lines +21 to +22
- name: action-pdk-validate-puppet-7
run: pdk validate --puppet-version=7
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd make version 7 an input with a default as well. That allows users to trivially override it. Also means switching 7 to 8 is just a one line change instead of two.

- run: gem install puppet_metadata --no-document
- name: Setup Test Matrix
id: get-outputs
run: metadata2gha --use-fqdn
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The FQDN part is only relevant for Beaker. Doesn't hurt, but it doesn't add anything either. I wonder if I should push it into beaker-hostgenerator itself, perhaps even make it the default.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for the default

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants