Comments (6)
npwalker
commented on June 20, 2024
The current code for determining what stage something should be in is based on the name of the check and I changed that to be more descriptive and it made it so there is no differentiation of stages any more.
https://github.com/puppetlabs/pdk-templates/blob/master/moduleroot/.gitlab-ci.yml.erb#L46-L47
The stage should be provided via config IMO but given the way it's written there is no way to do that. I suspect the easiest way to allow this is to have the user provide a hash with the key being the check to perform and stage, variables, image, etc... would be in a hash as the value. Something like:
parallel_spec:
stage: syntax
image: ruby:2.4.4
variables:
PUPPET_GEM_VERSION: '~> 5.5'
from pdk-templates.
cdenneen
commented on June 20, 2024
Ah so you broke it. LOL
Well maybe the check == 'spec' should be =~ instead.
Also not sure I agree with parallel being the default, maybe a Boolean to use? For some reason when using parallel and coverage for Rspec configure after suite check it tries to do coverage for each thread instead of as whole anymore. Once that’s fixed I think parallel is okay. (@DavidS @rodjek)
from pdk-templates.
dhollinger
commented on June 20, 2024
- I'm fixing issues 1, 2, and 4 (based on checkboxes starting from top to bottom).
- Issue 3 should not be fixed as the registry URL is considered a part of the Image name by Docker and other container technologies and the registry URL can be incredibly simple or incredibly complex depending on registry tool and specific user layout.
- The beaker job should not use any image/service other than
dindif using docker. As beaker itself controls the creation/destruction of the SUT, the only image that can be used with gitlab-ci and a docker running isdind
As to @npwalker's comment about the different ways to configure gitlab-ci.yml, there are hundreds of ways a user can configure .gitlab-ci.yml and this template is designed to create a default that is reminiscent of the defaults in .travis.yml. The defaults in this repo need to conform to what Puppetlabs has deemed best practice. The override and managed: false options are provided to .snyc.yml specifically for this reason. The defaults in this template for .gitlab-ci.yml don't work for me, either, so I use override: true and provide my own set of stages, jobs, etc.
from pdk-templates.
dhollinger
commented on June 20, 2024
Here's an example of a working gitlab ci config in .sync.yml:
.gitlab-ci.yml:
override: true
custom:
custom_stages:
- syntax
- unit
- acceptance
- deploy
bundler_args: '--without system_tests'
ruby_versions:
2.4.4:
checks:
- syntax
- lint
- rubocop
- metadata_lint
- spec
puppet_version: '~> 5.0'
tags:
- 'puppet-unit'
custom_jobs:
acceptance:
stage: acceptance
variables:
BEAKER_debug: 'true'
BEAKER_set: 'ec2'
BEAKER_PUPPET_COLLECTION: 'puppet5'
PLATFORM_type: 'appliance'
before_script:
- rvm use 2.4.4
- ruby -v
- bundle update
script:
- bundle exec rake acceptance
when: on_success
tags:
- puppet-acceptance
except:
- tags
- master
pages:
stage: deploy
image: ruby:2.4
before_script:
- bundle install
script:
- echo "Deploying Documentation"
- bundle exec rake strings:generate
artifacts:
paths:
- public
only:
- master
tags:
- puppet-acceptance
release:
stage: deploy
before_script:
- bundle update
script:
- 'GIT_SERVER=$(echo $CI_REPOSITORY_URL | cut -d"@" -f2 | cut -d"/" -f1)'
- 'git remote set-url origin git@$GIT_SERVER:$CI_PROJECT_PATH.git'
- 'bundle exec rake module_release'
only:
- master
when: on_success
tags:
- puppet-acceptance
build:
stage: deploy
before_script:
- bundle update
script:
- "\"export VERSION=$(grep \\\"version\\\": metadata.json | awk '{ print $2 }' | sed 's/,//' | sed 's/\\\"//g')\""
- bundle exec rake build
artifacts:
paths:
- pkg/internal-$CI_PROJECT_NAME-*.tar.gz
only:
- master
when: on_success
tags:
- puppet-acceptanceIt generates:
---
stages:
- syntax
- unit
- acceptance
- deploy
before_script:
- bundle -v
- rm Gemfile.lock || true
- gem update --system
- gem update bundler
- gem --version
- bundle -v
- bundle install --without system_tests
syntax-2.4.4:
stage: syntax
image: ruby:2.4.4
script:
- bundle exec rake syntax
variables:
PUPPET_GEM_VERSION: '~> 5.0'
tags:
- puppet-unit
lint-2.4.4:
stage: syntax
image: ruby:2.4.4
script:
- bundle exec rake lint
variables:
PUPPET_GEM_VERSION: '~> 5.0'
tags:
- puppet-unit
rubocop-2.4.4:
stage: syntax
image: ruby:2.4.4
script:
- bundle exec rake rubocop
variables:
PUPPET_GEM_VERSION: '~> 5.0'
tags:
- puppet-unit
metadata_lint-2.4.4:
stage: syntax
image: ruby:2.4.4
script:
- bundle exec rake metadata_lint
variables:
PUPPET_GEM_VERSION: '~> 5.0'
tags:
- puppet-unit
spec-2.4.4:
stage: unit
image: ruby:2.4.4
script:
- bundle exec rake spec
variables:
PUPPET_GEM_VERSION: '~> 5.0'
tags:
- puppet-unit
acceptance:
stage: 'acceptance'
variables:
BEAKER_debug: 'true'
BEAKER_set: 'ec2'
BEAKER_PUPPET_COLLECTION: 'puppet5'
PLATFORM_type: 'appliance'
before_script:
- rvm use 2.4.4
- ruby -v
- bundle update
script:
- bundle exec rake acceptance
when: 'on_success'
tags:
- puppet-acceptance
except:
- tags
- master
pages:
stage: 'deploy'
image: 'ruby:2.4'
before_script:
- bundle install
script:
- echo "Deploying Documentation"
- bundle exec rake strings:generate
artifacts:
paths:
- public
only:
- master
tags:
- puppet-acceptance
release:
stage: 'deploy'
before_script:
- bundle update
script:
- GIT_SERVER=$(echo $CI_REPOSITORY_URL | cut -d"@" -f2 | cut -d"/" -f1)
- git remote set-url origin git@$GIT_SERVER:$CI_PROJECT_PATH.git
- bundle exec rake module_release
only:
- master
when: 'on_success'
tags:
- puppet-acceptance
build:
stage: 'deploy'
before_script:
- bundle update
script:
- "export VERSION=$(grep \"version\": metadata.json | awk '{ print $2 }' | sed 's/,//' | sed 's/\"//g')"
- bundle exec rake build
artifacts:
paths:
- pkg/ntts-$CI_PROJECT_NAME-*.tar.gz
only:
- master
when: 'on_success'
tags:
- puppet-acceptanceNOTE - I am not using the beaker options, but my own acceptance job and providing my own rake/acceptance.rake file in the repo + the .sync.yml file
from pdk-templates.
dhollinger
commented on June 20, 2024
@cdenneen nokogiri installations options should be addressed as a core pdk-templates issue rather than just for gitlab-ci.yml.
The override option should be removing ALL default jobs and stages. I'll look at that when I have time.
For the caching. It's, in my opinion, better to run more jobs in parallel than one at a time. Maybe the option here is to have the rubocop or syntax job run in the first stage (called validate or syntax respectively) and then run everything else in the next stage. The unit tests should also benefit from the caching. I don't think beaker tests can benefit from the caching since Beaker, more or less, acts as another layer of abstraction between CI and the SUT.
from pdk-templates.
DavidS
commented on June 20, 2024
Closing out old beaker stuff.
from pdk-templates.
Related Issues (20)
- Invalid GitHub Actions Jobs if Honeycomb Unset
- Skip Honeycomb if Disabled HOT 1
- update deprecated setting in devcontainer.json
- YAML anchor in .sync.yml results in bad result HOT 6
- Enable puppet-lint-plugins also on Windows HOT 1
- Enhance templates to handle rules in .gitlab-ci.yml section of sync.yml HOT 1
- GitLab CI is failing due to rubocop-ast dependency under puppet6 HOT 1
- When honeycomb is disabled command `buildevents` is not known, but still used in github actions scripts HOT 1
- Update the auto_release workflow to include the REFERENCE.md generate command
- set/allow interruptible in gitlabci jobs
- Custom .gitlab-ci.yml settings for litmus not working as expected HOT 1
- `disable_legacy_facts: true` includes deprecated puppet-lint-legacy_facts-check gem HOT 5
- Cannot load puppet_blacksmith on fresh module HOT 3
- facter_implementation missing quotes HOT 2
- Cannot load github_changelog_generator/task HOT 1
- Allow puppet-lint fail_on_warnings to be explicitly disabled
- .gitlab-cy.yml missing in pdk-templates 3.0? HOT 6
- Wrong things added? HOT 2
- Should PDK also work with templates on our internal GitHub Enterprise? HOT 2
- networking key in default_facts.yml masks all values from rspec-puppet-facts HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pdk-templates.