Skip to content

(MAINT) Add CI workflow #310

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

Merged
merged 16 commits into from
Sep 29, 2022
Merged

(MAINT) Add CI workflow #310

merged 16 commits into from
Sep 29, 2022

Conversation

chelnak
Copy link
Contributor

@chelnak chelnak commented Sep 26, 2022

Prior to this commit puppet-strings relied on travis for ci. We have since moved away from travis and use GitHub actions.

This commit creates a new ci.yml workflow that runs on:

  • A nightly cron
  • pull request to main
  • workflow_dispatch

We also remove the legacy travis workflow.

In addition to the above there are also a number of rubocop fixes in this PR. These fixes were required to ensure that spec and linting tests were green.

@chelnak chelnak self-assigned this Sep 26, 2022
@chelnak chelnak requested a review from a team as a code owner September 26, 2022 09:22
@chelnak chelnak force-pushed the maint-add_ci_workflow branch 5 times, most recently from fcddc6d to ec68c99 Compare September 26, 2022 09:49
Prior to this commit puppet-strings relied on travis for ci. We have
since moved away from travis and use github actions.

This commit creates a new ci.yml workflow that runs on:

* A nightly cron
* pull request to main
* workflow_dispatch
This commit removes the legacy travis workflow from this repository
Prior to this commit Rubocop was constrained to an older version. This
was causing cop errors when executed with newer rubies.

This commit removes the version constraint from the Gemfile and bumps
the target ruby version in rubocops config to 2.5 which is the current
minimum supported version.
Prior to this commit the rubocop config in this repository differed from
configs used across the modules ecosystem.

This commit attempts to align the config and versions used.
@chelnak chelnak force-pushed the maint-add_ci_workflow branch 5 times, most recently from 1955993 to c0bd743 Compare September 28, 2022 09:55
@chelnak chelnak force-pushed the maint-add_ci_workflow branch from c0bd743 to 1bf8ef5 Compare September 28, 2022 09:57
@chelnak chelnak force-pushed the maint-add_ci_workflow branch from 1bf8ef5 to cd4efbd Compare September 28, 2022 10:31
raise RuntimeError, 'This face requires Ruby 1.9 or greater.' if RUBY_VERSION.match?(/^1\.8/)
raise "The 'yard' gem must be installed in order to use this face." unless Puppet.features.yard?
raise "The 'rgen' gem must be installed in order to use this face." unless Puppet.features.rgen?
raise 'This face requires Ruby 1.9 or greater.' if RUBY_VERSION.match?(%r{^1\.8})
Copy link
Contributor

Choose a reason for hiding this comment

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

The funny thing here is that .match? didn’t exist until Ruby 2.4.6.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm yes.. and to be honest given the minimum ruby for this gem is now 2.5x i wonder if these constraints could be removed?

Copy link
Member

@david22swan david22swan left a comment

Choose a reason for hiding this comment

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

A third of the way through so far, some small thoughts

@chelnak
Copy link
Contributor Author

chelnak commented Sep 28, 2022

@david22swan With regards to the _prefix parameter.

It looks like it is a requirement brought forward by inheritance.

The base class for our CodeObjects classes inherit from YARD::CodeObjects::NamespaceObject. This has an instance method called name that expects a parameter (prefix).

Given that our classes seem to build on the OO nature of YARD i'd be hesitant to remove it because we do not know whether other methods will be expecting an object with a signature of my_object.name(prefix).

I think what can be misleading here is using false as a default. I've seen others use more descriptive symbols in these cases. We could adopt this change here?

There is however documentation for the param on most of these methods that states it's intention:

# @param [Boolean] prefix whether to show a prefix. Ignored for Puppet group namespaces.

There may be more value ensuring that this message is constant across all of the CodeObjects classes.

What do you think?

@david22swan
Copy link
Member

Sounds good to me

@chelnak chelnak force-pushed the maint-add_ci_workflow branch from cd4efbd to ea5b786 Compare September 28, 2022 12:33
@chelnak chelnak force-pushed the maint-add_ci_workflow branch 2 times, most recently from 195e88d to ab3e011 Compare September 28, 2022 15:31
@chelnak chelnak force-pushed the maint-add_ci_workflow branch from ab3e011 to f68b2be Compare September 28, 2022 15:34
@@ -114,18 +114,18 @@ def output(name, data, undoc = nil)
@undocumented += undoc if undoc.is_a?(Integer)
data =
if undoc
('%5s (% 5d undocumented)' % [data, undoc])
"#{data} (#{undoc} undocumented)"
Copy link
Contributor

Choose a reason for hiding this comment

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

This is what the new output will look like if there is more than 9 of some type (assuming I didn’t read this wrong):

Files:                    1
Modules:                  0 (0 undocumented)
Classes:                  0 (0 undocumented)
Constants:                0 (0 undocumented)
Attributes:               0 (0 undocumented)
Methods:                  0 (0 undocumented)
Puppet Classes:           10 (0 undocumented)
Puppet Data Types:        0 (0 undocumented)
Puppet Data Type Aliases: 10 (10 undocumented)
Puppet Defined Types:     1 (0 undocumented)
Puppet Types:             0 (0 undocumented)
Puppet Functions:         0 (0 undocumented)
Puppet Providers:         0 (0 undocumented)
Puppet Plans:             0 (0 undocumented)
Puppet Tasks:             0 (0 undocumented)

I think that’s fine, especially since I imagine the vast majority of modules have fewer than <10 of anything. Just wanted to make it explicit.

Copy link
Contributor

@pmcmaw pmcmaw left a comment

Choose a reason for hiding this comment

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

Thanks for this @chelnak
These changes are well overdue! 👍

@pmcmaw
Copy link
Contributor

pmcmaw commented Sep 29, 2022

Merging as the outstanding status is for Travis CI which has been removed.

@pmcmaw pmcmaw merged commit e7e4444 into main Sep 29, 2022
@pmcmaw pmcmaw deleted the maint-add_ci_workflow branch September 29, 2022 09:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants