-
Notifications
You must be signed in to change notification settings - Fork 4
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
Add image build config and release script #18
Add image build config and release script #18
Conversation
<!-- Unset to prevent default inheritance --> | ||
<quarkus.container-image.insecure>false</quarkus.container-image.insecure> | ||
</properties> | ||
</profile> |
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.
In addition, you think we should generally leave it to local-horst?
Line 28 in 5d47d46
<quarkus.container-image.registry>localhost:5001</quarkus.container-image.registry> |
I guess, in theory, I'd like no hard-coded localhost
, but something that resolves via ENV_VAR?
Here is a "big fan" of $KO_DOCKER_REPO
like we do on golang
🙃
/cc @christophd
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.
"local-horst" 🤣
I am not tied to using this local config as a default. I can adjust the settings on my fork when testing locally. Feel free to remove and set a decent default value like quay.io or something
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 wanted to isolate changes for now, but sure it make sense to use ${env.KO_DOCKER_REPO}
.
A note here, quarkus doesn't like additional namespaces in registry
property, only host:port
combination. So kind.local
is fine, but not gcr.io/knative-nightly
- our default in release script. :)
Therefore I've used whole image
property here.
|
||
go 1.23.1 | ||
|
||
require knative.dev/hack v0.0.0-20241010131451-05b2fb30cb4d |
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 only need go.mod
to enable our hack scripts.
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.
sounds good, @dsimansk
Thanks a lot for getting into this
5d47d46
to
3d0d4ef
Compare
Nightly Prow job to test it out and publish the images: knative/infra#532 |
</property> | ||
</activation> | ||
<properties> | ||
<quarkus.container-image.image>${env.KO_DOCKER_REPO}/${project.artifactId}:${env.TAG}</quarkus.container-image.image> |
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.
@christophd @matzew currently the module names by directory and artifactId are different. E.g. <artifactId>kn-connector-aws-s3-source</artifactId>
for aws-s3-sink. Should we align those, or create a name property to be reflected in the image name?
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 see Eventing core is expecting kn prefixed name. That's fine for now.
if source.Spec.Aws.S3 != nil {
return "quay.io/openshift-knative/kn-connector-aws-s3-source:1.0-SNAPSHOT"
}
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.
🙈
let's fix that 🤣
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.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dsimansk, matzew The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Changes
In a nutshell, this will be driven by the same
release.sh
as rest of the components. I'll create a nightly Prow job to verify it first.IMO we could have at least another
kind
profile or some local one for development, but let's see.Fixes #6
/cc @matzew @christophd