samvera / samvera-circleci-orb Goto Github PK

After #36 is merged, the orb will have a straightforward place to preform integration testing, but does not currently have any tests.

Previous discussion has suggested running tests against Hyrax, or another core component.

Solr 8 rejects configuration uploads if authentication is not enabled, but this orb's consumers may not expect authentication to be required either.

This was a manual process introduced into https://github.com/samvera/hydra-editor/pull/168/files#diff-1d37e48f9ceff6d8030570cd36286a61R83 for samvera/hydra-editor#168.

Shellcheck is a job in Cirlcle's orb-tools orb. It runs the shellcheck utility against the run statements within our jobs and commands.

Shellcheck fails on the orb because we use CircleCI parameters in shell commands, among other reasons. It'd be nice to check our shell commands whenever the orb is updated.

bundle and bundle_for_gem cache ~/project/vendor/bundle which assumes the job running this command is using the default working directory (~/project). These commands should be generalized so they work with any working_directory.

I ran into this when modifying the example ruby config.yml when setting up a project, which sets working_directory: ~/repo, to use this orb.

While this is currently supported within this source code base, I am finding the following on the Orb Registry:

https://circleci.com/developer/orbs/orb/samvera/circleci-orb#executors-ruby

This should be cimg/, as is found within https://github.com/samvera-labs/samvera-circleci-orb/blob/main/src/executors/ruby.yml#L10

I ran into a weird CI build issue where one of the 10 parallelized containers failed with error starting container solr:7-alpine: Error: No such image: solr:7-alpine. I went looking on dockerhub and sure enough it looks like there isn't a 7-alpine anymore only 7 and 7-slim. I wonder if circleci is pulling from cache which will go away at some point and kill all of our builds. It would be nice to change the default in the orb before 1.0.

Here is the failed build: https://app.circleci.com/pipelines/github/samvera/hyrax/3587/workflows/52f26ad0-121b-4fa2-bfe0-3f090856d2b3/jobs/23332

Code Requirements

• Code must be released at version >= 1.0
• Good unit test coverage measured by community (e.g. 100% or 75% of what’s important)
  • Is this relevant?
• uses CI (Preferably CircleCI, unless there is a compelling reason to do something else)
  • Is this relevant?
• uses Coverage tool (coveralls or simplecov)
  • Is this relevant?
• Show compatibility with current Rails versions and other dependencies, when was it last tested; note compatibility with prior versions when available. Compatibility can be specified in the gemspec(s) or verified via CI matrix.
• Hierarchy of promises asserted in clearly defined acceptance tests

Documentation Requirements

• LICENSE file, Apache 2 (or compatible)
• README.md
• Statement of purpose
• Basic install steps
• Identify any volatile/experimental features
• How to contribute -> CONTRIBUTING.md
• How/Who to contact for help -> push out to all gems like CONTRIBUTING.md
• Known issues documented in github Issues tickets (not just listed in text)
• Tutorial / Walkthrough / Example usage
• Resolve TODO items in documents and remove them
• All Contributors should have signed Hydra Contibutor License Agreement (CLA)

Use Requirements

• Community use by three or more institutions
  • All core components use the orb now.
• In active use for six months
  • ActiveFedora started using it on March 20th.
• Has an ongoing maintenance plan.

I wonder if it makes sense to cache the output of rubocop to reduce the time it takes to run since our files aren't usually changing that much and it can save significant amount of time locally. I'm not sure exactly how rubocop's caching works and if it would work to do it in a CI environment or what exactly the cache key should look like.

See https://docs.rubocop.org/rubocop/usage/caching.html

The build attempts to publish a dev:alpha tag of the orb but this is currently failing with an AUTHORIZATION_FAILURE message. I'm also unable to publish locally either using my preconfigured token or manually specifying the token used by the build.

Currently, the latest release is not rendered on the README.md for this core component.

This is necessary to resolve #55

As discovered within https://github.com/samvera/browse-everything/pull/403/files#r898011114, there seem to be cases where the Ruby and Rails versions are used to generate CircleCI cache keys which cannot readily be reused without introducing breaking changes for a given branch.

See https://wiki.lyrasis.org/display/samvera/Samvera+Branch+Renaming+WG+Charter

Circle is replacing their current docker images with these new ones, which are in various states of stability.

This week, I spent quite a bit of time tracking down what dependencies were used with build. I ended up writing a script that uses bundle list and determines the date of each gem version's release. (see https://github.com/samvera/maintenance/blob/master/script/bundled-gem-release-dates.rb)

The problem is exacerbated with our EngineCart practice, when we push up sometimes we bundle update other times we use the cache. Knowing what's in play for a given build takes considerable sleuthing.

What I am looking for is a simple way to look at a build and see the list of bundled gems used. We can kind of do this by looking at the bundle install, but with caching that may not be in each build. Ideally, we'd have a file that could say "these were the gem versions used for this build."

On my machine, bundle list takes 0.31s for Hyrax. I do not believe the generation of this artifact would add much more than 1s to a Hyrax build.

This blocks the progress on #19

In the executors the solr container is set to 7-alpine and is not configurable when most of the other containers have a parameter to allow choosing a different version. Solr version should be configurable like the other services.

See https://github.com/samvera-labs/samvera-circleci-orb/blob/master/src/executors/ruby_fcrepo_solr_redis.yml#L23

This follows the proposed maintenance reorganization within samvera/maintenance#137

See CCI docs.

In short, while unauthenticated docker image pulls may work, this is not guaranteed in the future.

Thanks to @cjcolvar for bringing this up.

In the parallel builds in a CI run (e.g. https://app.circleci.com/pipelines/github/samvera/hyrax/3718/workflows/e032bfbc-1c26-4add-83e4-1975bd88a336/jobs/24758), looking at the "Save bundle cache" step, the cache key is different for each run.

Leading suspect is the find generating the cache key in the bundle command

• Draft release notes for distribution.
• Announce release plans on Samvera Tech listserv, Tech call, and #dev Slack channel.
• Check for samvera/circleci-orb@0 in Samvera repos and create PRs for the current version, 0.3.2.
• Check for samvera/circleci-orb@0 outside of Samvera and create issue for upcoming release.
• Attempt PR for current dev version for Hyrax (this is expected to break).
• Release the thing!
• Announce the release on Samvera Tech and Tech call.

The goal is to finish the release before the end of March.

Related to #19

Derived from samvera/maintenance#89

This week, I spent quite a bit of time tracking down what dependencies were used with build. I ended up writing a script that uses bundle list and determines the date of each gem version's release. (see https://github.com/samvera/maintenance/blob/master/script/bundled-gem-release-dates.rb)

The problem is exacerbated with our EngineCart practice, when we push up sometimes we bundle update other times we use the cache. Knowing what's in play for a given build takes considerable sleuthing.

What I am looking for is a simple way to look at a build and see the list of bundled gems used. We can kind of do this by looking at the bundle install, but with caching that may not be in each build. Ideally, we'd have a file that could say "these were the gem versions used for this build."

On my machine, bundle list takes 0.31s for Hyrax. I do not believe the generation of this artifact would add much more than 1s to a Hyrax build.

The orb currently uses the samvera/fcrepo4 image to setup Fedora for testing. For applications moving to Hyrax v5 for instance, and using Fedora 6 and Valkyrie, the orb currently does not provide any simple method to spin up a Fedora 6 container.

Currently, one cannot use the install_solr_core command to use the default Solr configuration provided within the active-fedora Gem (such as https://github.com/samvera/active_fedora/blob/master/lib/active_fedora/rake_support.rb#L21). Please see https://github.com/samvera/hydra-works/pull/366/files#r282064453 for reference.

The orb should own the specifics of creating a URL for the database it provides. This would help with samvera/hyrax#4397, and other postgres-using implementors.