-
Notifications
You must be signed in to change notification settings - Fork 84
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
adds ways to detect more pipelines in mconvert apkbuild #1235
base: main
Are you sure you want to change the base?
adds ways to detect more pipelines in mconvert apkbuild #1235
Conversation
Signed-off-by: Mritunjay <mritunjay.sharma@chainguard.dev>
@@ -328,6 +331,7 @@ func (c Context) buildFetchStep(ctx context.Context, converter ApkConvertor) err | |||
} | |||
|
|||
// maps APKBUILD values to mconvert | |||
// Question: Should not we return an error here for better error handling? | |||
func (c ApkConvertor) mapconvert() { |
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.
Should we return error here for better error handling now that we detect pipelines?
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 I would 👍
matches := re.FindAllString(outputStr, -1) | ||
|
||
// Join matches into a single string separated by space and backslash | ||
opts := strings.Join(matches, " \\\n") |
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 haven't seen opts being added for the existing pipelines but I still attempted to add here but it uses regex, are we intentionally avoiding it or should we add it? If yes, I can refactor it to be used by other pipelines too
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.
Good question -- I wonder if some of these opts would overlap with the existing pipeline inputs? It might make sense to try to map some of these to inputs if we can.
Earlier we were only detecting We can observe that with this change, we are reaching all the more closer to what the final wolfi yaml looks like as it helps them detect those pipelines. If this way looks good, I will add tests and further refactor it : New glu.yaml: # Generated from https://git.alpinelinux.org/aports/plain/main/glu/APKBUILD
package:
name: glu
version: 9.0.3
epoch: 0
description: Mesa OpenGL Utility library
copyright:
- license: SGI-B-1.1 AND SGI-B-2.0
environment:
contents:
packages:
- autoconf
- automake
- build-base
- busybox
- ca-certificates-bundle
- mesa-dev
- meson
pipeline:
- uses: fetch
with:
expected-sha256: bd43fe12f374b1192eb15fe20e45ff456b9bc26ab57f0eee919f96ca0f8a330f
uri: https://mesa.freedesktop.org/archive/glu/glu-${{package.version}}.tar.xz
- uses: meson/configure
with:
opts: |-
-Db_lto=true \
-Ddefault_library=shared \
-Dgl_provider=osmesa
- uses: meson/compile
- uses: meson/install
subpackages:
- name: glu-dev
pipeline:
- uses: split/dev
dependencies:
runtime:
- glu
- mesa-dev
description: glu dev Old glu yaml: # Generated from https://git.alpinelinux.org/aports/plain/main/glu/APKBUILD
package:
name: glu
version: 9.0.3
epoch: 0
description: Mesa OpenGL Utility library
copyright:
- license: SGI-B-1.1 AND SGI-B-2.0
environment:
contents:
packages:
- autoconf
- automake
- build-base
- busybox
- ca-certificates-bundle
- mesa-dev
- meson
pipeline:
- uses: fetch
with:
expected-sha256: bd43fe12f374b1192eb15fe20e45ff456b9bc26ab57f0eee919f96ca0f8a330f
uri: https://mesa.freedesktop.org/archive/glu/glu-${{package.version}}.tar.xz
- uses: autoconf/configure
- uses: autoconf/make
- uses: autoconf/make-install
- uses: strip
subpackages:
- name: glu-dev
pipeline:
- uses: split/dev
dependencies:
runtime:
- glu
- mesa-dev
description: glu dev Wolfi glu yaml: package:
name: glu
version: 9.0.3
epoch: 0
description: "Mesa OpenGL Utility library"
copyright:
- license: SGI-B-1.1
dependencies:
runtime:
environment:
contents:
packages:
- build-base
- mesa-dev
- mesa-osmesa
- meson
- ninja
- wolfi-base
pipeline:
- uses: fetch
with:
uri: https://mesa.freedesktop.org/archive/glu/glu-${{package.version}}.tar.xz
expected-sha512: b2781059c0e176192c3fc0d7244645020937a463311171efddb9f35fb94ee43faabcf627fa7f429d48fceaf6dd9c5adb69c86c7a21ec4ea490f4ab143d52e3ba
- uses: meson/configure
with:
opts: |
-Db_lto=true \
-Ddefault_library=shared \
-Dgl_provider=osmesa
- uses: meson/compile
- uses: meson/install
- uses: strip
update:
enabled: true
release-monitor:
identifier: 13518 The key difference between generarted glu.yaml and wolfi glu.yaml is in opts and I am still trying to fix it In generated it looks like opts uses: opts: |-
-Db_lto=true \ while wolfi yaml uses: opts: |
-Db_lto=true \
-Ddefault_libra The extra |
printer := syntax.NewPrinter() | ||
err := printer.Print(&output, c.Apkbuild.Funcs["build"]) | ||
if err != nil { | ||
fmt.Errorf("failed to print build function: %w", err) |
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.
fmt.Errorf("failed to print build function: %w", err) | |
return fmt.Errorf("failed to print build function: %w", err) |
@@ -328,6 +331,7 @@ func (c Context) buildFetchStep(ctx context.Context, converter ApkConvertor) err | |||
} | |||
|
|||
// maps APKBUILD values to mconvert | |||
// Question: Should not we return an error here for better error handling? | |||
func (c ApkConvertor) mapconvert() { |
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 I would 👍
c.GeneratedMelangeConfig.Pipeline = append(c.GeneratedMelangeConfig.Pipeline, config.Pipeline{Uses: "autoconf/make"}) | ||
c.GeneratedMelangeConfig.Pipeline = append(c.GeneratedMelangeConfig.Pipeline, config.Pipeline{Uses: "autoconf/make-install"}) | ||
c.GeneratedMelangeConfig.Pipeline = append(c.GeneratedMelangeConfig.Pipeline, config.Pipeline{Uses: "strip"}) | ||
// default: |
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 might want to keep the default as "make" as before, or at least scaffold out the metadata with no pipeline?
outputStr := output.String() | ||
|
||
// Define the regular expression to find options in the form of -<option>=<value> or --<option>=<value> | ||
re := regexp.MustCompile(`--?\w[-\w]*=[^\\\s]+`) |
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 would add a few test cases here to make sure this does what we expect.
matches := re.FindAllString(outputStr, -1) | ||
|
||
// Join matches into a single string separated by space and backslash | ||
opts := strings.Join(matches, " \\\n") |
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.
Good question -- I wonder if some of these opts would overlap with the existing pipeline inputs? It might make sense to try to map some of these to inputs if we can.
Melange Pull Request Template
Functional Changes
Notes:
SCA Changes
Notes:
Linter
Notes: