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

pipelines/ruby: add new test pipelines #1483

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

Conversation

Dentrax
Copy link
Contributor

@Dentrax Dentrax commented Sep 9, 2024

This PR adds new pipelines for Ruby:

  • ruby/test
  • ruby/require

Example usages:

- uses: ruby/test
  with:
    command: ruby -e "require 'json'"

- uses: ruby/require
  with:
    require: json

- uses: ruby/require
  with:
    requires: |
      require 'json'

@Dentrax Dentrax changed the title pipelines/ruby: add new pipelines to ruby packages pipelines/ruby: add new test pipelines for Ruby Sep 9, 2024
@Dentrax Dentrax changed the title pipelines/ruby: add new test pipelines for Ruby pipelines/ruby: add new test pipelines Sep 9, 2024
@Dentrax Dentrax force-pushed the pipelines-ruby-test branch 6 times, most recently from b4554e1 to 7b51ab9 Compare September 9, 2024 17:43
@Dentrax Dentrax marked this pull request as ready for review September 9, 2024 17:58
Copy link
Member

@EyeCantCU EyeCantCU left a comment

Choose a reason for hiding this comment

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

This is great. Left a few comments. Can we also document the usage of the pipeline in melange's docs?

@@ -0,0 +1,14 @@
name: Test a Ruby package
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 we should get rid of this. We're not doing anything inherently specific to Ruby

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems we have name: field defined on each pipeline, do you say we should omit this field?

Copy link
Member

Choose a reason for hiding this comment

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

Sorry, the pipeline. It looks like it does the same thing a runs would do

Copy link
Contributor

Choose a reason for hiding this comment

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

so drop this?


needs:
packages:
- wolfi-base
Copy link
Member

Choose a reason for hiding this comment

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

Wolfi base is implicit. We don't need to define it

name: Test a Ruby package require, with optional load clause

needs:
packages:
Copy link
Member

Choose a reason for hiding this comment

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

We should add Ruby here, passed as an input. See go/build for what I'm talking about

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just checked the other Ruby pipelines and it seems we didn't include the Ruby, was wondering if there was any reason. 🤔

Copy link
Member

@EyeCantCU EyeCantCU Sep 9, 2024

Choose a reason for hiding this comment

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

I don't think it'd ever been considered that pipeline should fetch the toolchain. go/build didn't offer this functionality until a few months ago either. We should provide it because it's helpful, and we can implicitly pull in ruby without defining it in the environment

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That makes sense, I've added Ruby here and couldn't pass the CI error: https://github.com/chainguard-dev/melange/actions/runs/10788637898/job/29919880644?pr=1483#step:9:1071 - for some reason, it doesn't find ruby-3.2 even its there.

Copy link
Contributor

Choose a reason for hiding this comment

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

So , yeah... several of the pipelines that I've added have this flaw in that they don't declare needs that it'd be nice if they did. py/pip-build-install for example needs bot a pip and a python, but doesn't declare either.

The reason is that it takes python as an input (the python version to use).

I don't think you can use a input to a pipeline in its needs. It would be cleaner here if you could. This specific case would be nice in that you could then:

needs:
  packages:
    - ruby-${{inputs.version}}

And then have a inputs that declared 3.2 as the default or something.

If that happens to work, (including with a range section like we're doing in python) then I guess I'd suggest doing that, but other wise I'd not bother.

Another option would be to have a pipeline per ruby-version (ruby/require-3.2, ruby/require-3.3). I suspect that would work, and you could reduce copy/paste code between ruby/require-3.2 and ruby/require-3.3 with nested pipelines. But if you were doing per-ruby versions i'd want that in wolfi-dev/os rather than melange proper.

So...
that was all long winded way of saying "I think this is fine".


pipeline:
- runs: |
set +x
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this applies to the rest of the pipeline

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a copy-paste thing from python/import pipeline actually. I'm checking the CI logs here but couldn't see the instructions either.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, happy to be wrong here, but I don't believe it's transient to the rest of the pipeline. Will let someone that knows for sure chime in

Copy link
Contributor

Choose a reason for hiding this comment

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

it does "apply", in that it turns off '-x' option (making it not spew bash debug to stderr).

@Dentrax Dentrax force-pushed the pipelines-ruby-test branch 4 times, most recently from f6c177d to 71843e5 Compare September 10, 2024 09:22
Copy link
Contributor

@smoser smoser left a comment

Choose a reason for hiding this comment

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

with regard to the error you're seeing [here]:

 2024/09/10 09:27:54 INFO running step "Test a Ruby package require, with optional load clause"
2024/09/10 09:27:54 WARN /bin/sh: ruby-3.2: not found
2024/09/10 09:27:54 INFO ruby-3.2 -e "require 'json'": FAIL
2024/09/10 09:27:54 INFO ERROR: failed to test package. the test environment has been preserved:
2024/09/10 09:27:54 INFO   workspace dir: /tmp/melange-workspace-1987892197
2024/09/10 09:27:54 INFO   guest dir: /tmp/melange-guest-1360058723

A couple things:

  1. ruby-3.2 does not provide an executable named 'ruby-3.2'. The package is
    named ruby-3.2 but it only provides /usr/bin/ruby. So thats why you get
    'ruby-3.2' command not found.

  2. If the 'inputs.ruby' is providing the package rather than an executable
    name (in python it provides an executable name), to install, and we are assuming that a ruby (ruby-3.X) package will always install /usr/bin/ruby, then you can ditch the searching for a binary (lines 43-57 entirely), and make 'RUBY='ruby' on line 29.

  3. in e2e-tests/ruby3.2-json-test.yaml you should actually drop the 'packages:' section, because the 'needs' should fulfill that.

@Dentrax
Copy link
Contributor Author

Dentrax commented Sep 11, 2024

Thank you so much @smoser! I just updated the PR and hit a new issue:

ruby-3.2-3.2.4-r1.apk disqualified because ruby-3.3-3.3.5-r1.apk already provides cmd:erb

That's probably due to I set ${{inputs.ruby}}=ruby so it installs the ruby-3.3 (latest) whereas I have ruby-3.2 in the test pipeline. But I'd like to set ruby-3.2 as a default package since most of Wolfi packages using this version. That's why I had to set default: ruby-3.2.

fi
}

if [ "$RUBY" = "ruby" ]; then
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the default 'DEFAULT' or some other non-usable string is prefereable here.
The caller could very legitmately have ruby in the PATH and want that to be tested. At least I can't think of a good reason to "fix" it for them.

Did you have one?

@Dentrax
Copy link
Contributor Author

Dentrax commented Oct 29, 2024

Thank you @smoser! I made some changes according to your reviews here, could you PTAL when possible? It seems the CI is now green but not sure whether it's false-positive.

@@ -0,0 +1,14 @@
name: Test a Ruby package
Copy link
Contributor

Choose a reason for hiding this comment

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

so drop this?

default: DEFAULT
version:
description: Which Ruby version to use
default: 3.2
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe if you're letting it declare version, then don't let it declare 'ruby' ?
because what happens if i do:

ruby: ruby3.3
version: ruby3.2

I tihnk one or the other.
Either take ruby and just don't bother with needs.
or take version , set needs, and use either explicitly use /usr/bin/ruby${{inputs.version}} or just assume in PATH as ruby${{inputs.version}}.

thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm kind of thinking out loud here. I think its wierd to take both, but it was very useful to in the python ones to use DEFAULT and pick the right /usr/bin/python3.XX when there was only one, and error in other cases.

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.

3 participants