-
Notifications
You must be signed in to change notification settings - Fork 115
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
Split manifest and update CI #852
Conversation
Initial version of this PR had no default manifest symlink but this does not work well with https://github.com/coreos/coreos-assembler/blob/main/src/cmd-init#L135 (from coreos/coreos-assembler@480c239 & coreos/coreos-assembler@4781e46) |
/retest |
Setup symlinks for COSA compatibility.
/retest |
@travier: 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/test-infra repository. I understand the commands that are listed here. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: HuijingHei, travier 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 |
Hum, I should have added a hold here until the discussion had reached a consensus on this one vs the other alternative. Well, we can always redo the layout later if we decide to. |
Support for the logic introduced in [1]: - Look for a default manifest - If none found, look for a script to select the default manifest - If not found, error out Enable shipping openshift/os with no default manifest selected. [1] openshift/os#852. Partially revert: 480c239 init: Require specifying a config repository
Support for the logic introduced in [1]: - Look for a default manifest - If none found, look for a script to select the default manifest - If not found, error out Enable shipping openshift/os with no default manifest selected. [1] openshift/os#852. Partially revert: 480c239 init: Require specifying a config repository
Hmm, yeah I'm really not a fan of requiring running a script to set up the config dir. It makes things less declarative and more opaque. If we need to fix cosa to handle symlinks correctly for some files, then can we do that instead? |
Agree that this is not ideal but I don't have a better idea right now. The last workaround was basically to copy the entire repo into the subfolder which is even less ideal: https://github.com/openshift/os/pull/849/files#diff-cf4ac67e6195e36ef10dd53e72af30a0346517d3faf3857f88e74204c7373e3bR53-R66 |
See also coreos/coreos-assembler#2934 |
We could make |
And:
|
I opened coreos/coreos-assembler#2936 which should fix the symlinking issues that Micah was hitting in #803 (comment). I'm cool with moving away from subdirs in the future, but short-term I'd still prefer that over a setup script. |
Let's do coreos/coreos-assembler#2934 (comment) then and decide on an interface to select the variant/version from a file? |
Otherwise we would be changing the layout to use sub dirs to then change it again to remove the sub dir. |
I'm OK with that if others prefer, but would be more comfortable just reverting this and fixing up the subdirs approach. Then we can take our time to design something better. |
If we decide to move forward to using subdirs then I can make a PR to move the current state to that as the manifests are now ready and split. Reverting this one will have us re-review the split for nothing. |
Several variants may be provided from a single Git config repo: - If no variant is explicitely selected then the default `manifest.yaml` will be used. - If there is no `manifest.yaml` file provided by default in the repo, then COSA will read the `variant_default` file to figure out which variant to use by default. - If you explicitely specify a variant as parameter then COSA will read the corresponding `variant_$VARIANT` file and use that as default instead, overriding any default set in the repo. See: openshift/os#852. Reworks: 480c239 init: Require specifying a config repository
Several variants may be provided from a single Git config repo: - If no variant is explicitly selected then the default `manifest.yaml` will be used. - If there is no `manifest.yaml` file provided by default in the repo, then COSA will read the `variant_default` file to figure out which variant to use by default. - If you explicitly specify a variant as parameter then COSA will read the corresponding `variant_$VARIANT` file and use that as default instead, overriding any default set in the repo. See: openshift/os#852. Reworks: 480c239 init: Require specifying a config repository
Remove the current multi-version setup that was merged in openshift#852 as we are moving to a COSA based setup.
Several variants may be provided from a single Git config repo: - If no variant is explicitly selected then the default `manifest.yaml` will be used. - If there is no `manifest.yaml` file provided by default in the repo, then COSA will read the `variant_default` file to figure out which variant to use by default. - If you explicitly specify a variant as parameter then COSA will read the corresponding `variant_$VARIANT` file and use that as default instead, overriding any default set in the repo. See: - openshift/os#852 - openshift/os#901 Reworks: 480c239 init: Require specifying a config repository
Several variants may be provided from a single Git config repo: - If no variant is explicitly selected then the default `manifest.yaml` will be used. - If there is no `manifest.yaml` file provided by default in the repo, then COSA will read the `variant_default` file to figure out which variant to use by default. - If you explicitly specify a variant as parameter then COSA will read the corresponding `variant_$VARIANT` file and use that as default instead, overriding any default set in the repo. See: - openshift/os#852 - openshift/os#901 Reworks: 480c239 init: Require specifying a config repository
Several variants may be provided from a single Git config repo: - If no variant is explicitly selected then the default `manifest.yaml` will be used. - If there is no `manifest.yaml` file provided by default in the repo, then COSA will read the `variant_default` file to figure out which variant to use by default. - If you explicitly specify a variant as parameter then COSA will read the corresponding `variant_$VARIANT` file and use that as default instead, overriding any default set in the repo. See: - openshift/os#852 - openshift/os#901 Reworks: 480c239 init: Require specifying a config repository
Several variants may be provided from a single Git config repo: - If no variant is explicitly selected then the default `manifest.yaml` will be used. - If there is no `manifest.yaml` file provided by default in the repo, then COSA will read the `variant_default` file to figure out which variant to use by default. - If you explicitly specify a variant as parameter then COSA will read the corresponding `variant_$VARIANT` file and use that as default instead, overriding any default set in the repo. See: - openshift/os#852 - openshift/os#901 Reworks: 480c239 init: Require specifying a config repository
Several variants may be provided from a single Git config repo: - If no variant is explicitly selected then the default `manifest.yaml` will be used. - If there is no `manifest.yaml` file provided by default in the repo, then COSA will read the `variant_default` file to figure out which variant to use by default. - If you explicitly specify a variant as parameter then COSA will read the corresponding `variant_$VARIANT` file and use that as default instead, overriding any default set in the repo. See: - openshift/os#852 - openshift/os#901 Reworks: 480c239 init: Require specifying a config repository
Several variants may be provided from a single Git config repo: - If no variant is explicitly selected then the default `manifest.yaml` will be used. - If there is no `manifest.yaml` file provided by default in the repo, then COSA will read the `variant_default` file to figure out which variant to use by default. - If you explicitly specify a variant as parameter then COSA will read the corresponding `variant_$VARIANT` file and use that as default instead, overriding any default set in the repo. See: - openshift/os#852 - openshift/os#901 Reworks: 480c239 init: Require specifying a config repository
Several variants may be provided from a single Git config repo: - If no variant is explicitly selected then the default `manifest.yaml` will be used. - If there is no `manifest.yaml` file provided by default in the repo, then COSA will read the `variant_default` file to figure out which variant to use by default. - If you explicitly specify a variant as parameter then COSA will read the corresponding `variant_$VARIANT` file and use that as default instead, overriding any default set in the repo. See: - openshift/os#852 - openshift/os#901 Reworks: 480c239 init: Require specifying a config repository
Several variants may be provided from a single Git config repo: - If no variant is explicitly selected then the default `manifest.yaml` will be used. - If there is no `manifest.yaml` file provided by default in the repo, then COSA will read the `variant_default` file to figure out which variant to use by default. - If you explicitly specify a variant as parameter then COSA will read the corresponding `variant_$VARIANT` file and use that as default instead, overriding any default set in the repo. See: - openshift/os#852 - openshift/os#901 Reworks: 480c239 init: Require specifying a config repository
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - https://github.com/openshift/os/pull/XYZ # TODO Reworks: 480c239 init: Require specifying a config repository
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - openshift/os#958 Reworks: 480c239 init: Require specifying a config repository
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - openshift/os#958 Reworks: 480c239 init: Require specifying a config repository
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - openshift/os#958 Reworks: 480c239 init: Require specifying a config repository
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - openshift/os#958 Reworks: 480c239 init: Require specifying a config repository
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - openshift/os#958 Reworks: 480c239 init: Require specifying a config repository
ci: Add an explicitly named test entry for COSA CI
Adding an explicit test entry point will enable us to focus on tests
that matter for COSA CI (such as buildextends for all platforms) and not
on general RHCOS testing.
ci: Remove now unused test names
manifests: Split into common & RHEL 8.6 specific manifests
Add script to select which version to build
ci: Expllcitly select the version to build