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

NO-JIRA: extensions/Dockerfile: use latest Fedora to generate repo #1583

Merged

Conversation

jlebon
Copy link
Member

@jlebon jlebon commented Aug 22, 2024

In this stage of the build, we're just using Fedora to generate repodata. Since this is a pretty basic operation, let's just always use the latest Fedora instead of hardcoding a specific version. This ensures that e.g. we're never going to use an EOL Fedora release.

This became an issue after 8301c67 ("extensions/Dockerfile: use the FCOS defined fedora.repo to set up container"), which was backported to older RHCOS branches that used EOL Fedora releases. Before, we were using the mirrors, which papered over the fact that the content for EOL releases actually moved to another location. But now that we're using the canonical Fedora server, we're directly exposed to that.

Really, we should just stop hardcoding Fedora versions in this repo. We shouldn't be using EOL releases at all as part of our builds or tests. (Obviously a massive offender here is cosa... though that's a discussion of its own.)

See also: #1546

In this stage of the build, we're just using Fedora to generate
repodata. Since this is a pretty basic operation, let's just always use
the latest Fedora instead of hardcoding a specific version. This ensures
that e.g. we're never going to use an EOL Fedora release.

This became an issue after 8301c67 ("extensions/Dockerfile: use the
FCOS defined fedora.repo to set up container"), which was backported
to older RHCOS branches that used EOL Fedora releases. Before, we were
using the mirrors, which papered over the fact that the content for EOL
releases actually moved to another location. But now that we're using
the canonical Fedora server, we're directly exposed to that.

Really, we should just stop hardcoding Fedora versions in this repo. We
shouldn't be using EOL releases at all as part of our builds or tests.
(Obviously a massive offender here is cosa... though that's a discussion
of its own.)

See also: openshift#1546
@openshift-ci openshift-ci bot requested review from c4rt0 and cverna August 22, 2024 17:12
@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 22, 2024
Copy link
Contributor

@marmijo marmijo left a comment

Choose a reason for hiding this comment

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

LGTM

@marmijo
Copy link
Contributor

marmijo commented Aug 22, 2024

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Aug 22, 2024
Copy link
Contributor

openshift-ci bot commented Aug 22, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aaradhak, jlebon, marmijo

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:
  • OWNERS [aaradhak,jlebon,marmijo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@marmijo
Copy link
Contributor

marmijo commented Aug 22, 2024

/retest

@marmijo
Copy link
Contributor

marmijo commented Aug 22, 2024

/label acknowledge-critical-fixes-only

@openshift-ci openshift-ci bot added the acknowledge-critical-fixes-only Indicates if the issuer of the label is OK with the policy. label Aug 22, 2024
@marmijo
Copy link
Contributor

marmijo commented Aug 22, 2024

/retitle NO-JIRA: extensions/Dockerfile: use latest Fedora to generate repo

@openshift-ci openshift-ci bot changed the title extensions/Dockerfile: use latest Fedora to generate repo NO-JIRA: extensions/Dockerfile: use latest Fedora to generate repo Aug 22, 2024
@openshift-ci-robot
Copy link

@jlebon: This pull request explicitly references no jira issue.

In response to this:

In this stage of the build, we're just using Fedora to generate repodata. Since this is a pretty basic operation, let's just always use the latest Fedora instead of hardcoding a specific version. This ensures that e.g. we're never going to use an EOL Fedora release.

This became an issue after 8301c67 ("extensions/Dockerfile: use the FCOS defined fedora.repo to set up container"), which was backported to older RHCOS branches that used EOL Fedora releases. Before, we were using the mirrors, which papered over the fact that the content for EOL releases actually moved to another location. But now that we're using the canonical Fedora server, we're directly exposed to that.

Really, we should just stop hardcoding Fedora versions in this repo. We shouldn't be using EOL releases at all as part of our builds or tests. (Obviously a massive offender here is cosa... though that's a discussion of its own.)

See also: #1546

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Copy link
Contributor

openshift-ci bot commented Aug 22, 2024

@jlebon: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@openshift-merge-bot openshift-merge-bot bot merged commit aa71938 into openshift:master Aug 22, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
acknowledge-critical-fixes-only Indicates if the issuer of the label is OK with the policy. approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants