-
Notifications
You must be signed in to change notification settings - Fork 110
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
base: main
Are you sure you want to change the base?
Conversation
b4554e1
to
7b51ab9
Compare
There was a problem hiding this 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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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. 🤔
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
f6c177d
to
71843e5
Compare
There was a problem hiding this 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:
-
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. -
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. -
in e2e-tests/ruby3.2-json-test.yaml you should actually drop the 'packages:' section, because the 'needs' should fulfill that.
71843e5
to
ae4bafc
Compare
Thank you so much @smoser! I just updated the PR and hit a new issue:
That's probably due to I set |
fi | ||
} | ||
|
||
if [ "$RUBY" = "ruby" ]; then |
There was a problem hiding this comment.
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?
Signed-off-by: Dentrax <[email protected]>
Signed-off-by: Dentrax <[email protected]>
ae4bafc
to
67bf807
Compare
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
This PR adds new pipelines for Ruby:
ruby/test
ruby/require
Example usages: