samvera / samvera-circleci-orb Goto Github PK
View Code? Open in Web Editor NEWAn orb with a set of tasks to centralize testing infrastructure for Samvera Core Components
License: Apache License 2.0
An orb with a set of tasks to centralize testing infrastructure for Samvera Core Components
License: Apache License 2.0
This blocks the progress on #19
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 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.
This follows the proposed maintenance reorganization within samvera/maintenance#137
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
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.
samvera/circleci-orb@0
in Samvera repos and create PRs for the current version, 0.3.2.samvera/circleci-orb@0
outside of Samvera and create issue for upcoming release.The goal is to finish the release before the end of March.
Related to #19
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.
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.
Solr 8 rejects configuration uploads if authentication is not enabled, but this orb's consumers may not expect authentication to be required either.
See CCI docs.
In short, while unauthenticated docker image pulls may work, this is not guaranteed in the future.
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 was a manual process introduced into https://github.com/samvera/hydra-editor/pull/168/files#diff-1d37e48f9ceff6d8030570cd36286a61R83 for samvera/hydra-editor#168.
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.
Derived from samvera/maintenance#89
This is necessary to resolve #55
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.
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
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
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.