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

build: track generated CSV, and validate #8862

Closed
wants to merge 1 commit into from

Conversation

BlaineEXE
Copy link
Member

Start tracking the generated CSV, and validate that they don't change in
builds.

Signed-off-by: Blaine Gardner blaine.gardner@redhat.com

Description of your changes:

Which issue is resolved by this Pull Request:
Resolves #

Checklist:

  • Commit Message Formatting: Commit titles and messages follow guidelines in the developer guide.
  • Skip Tests for Docs: Add the flag for skipping the build if this is only a documentation change. See here for the flag.
  • Skip Unrelated Tests: Add a flag to run tests for a specific storage provider. See test options.
  • Reviewed the developer guide on Submitting a Pull Request
  • Documentation has been updated, if necessary.
  • Unit tests have been added, if necessary.
  • Integration tests have been added, if necessary.
  • Pending release notes updated with breaking and/or notable changes, if necessary.
  • Upgrade from previous release is tested and upgrade user guide is updated, if necessary.
  • Code generation (make codegen) has been run to update object specifications, if necessary.

@BlaineEXE BlaineEXE force-pushed the generate-and-track-csv branch 13 times, most recently from d51c8b6 to 85c5e0e Compare September 29, 2021 16:05
@BlaineEXE BlaineEXE marked this pull request as ready for review September 29, 2021 16:08
images/ceph/Makefile Outdated Show resolved Hide resolved
@@ -115,7 +115,7 @@ do.build.platform.%:

do.build.parallel: $(foreach p,$(PLATFORMS), do.build.platform.$(p))

build: csv-clean build.common ## Only build for linux platform
Copy link
Member Author

Choose a reason for hiding this comment

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

csv-clean here was causing changes to tracked CSVs on build.

@BlaineEXE BlaineEXE force-pushed the generate-and-track-csv branch 3 times, most recently from bd2e09b to c81f89d Compare September 29, 2021 20:43
Comment on lines -173 to -174
csv-clean: ## Remove existing OLM files.
@$(MAKE) -C images/ceph csv-clean
Copy link
Member Author

Choose a reason for hiding this comment

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

csv-clean in general was causing changes to tracked CSVs on build, so I just remove it.

@$(MAKE) -C images/ceph csv-clean

GEN_CRD_TEMP := /tmp/rook-ceph-gen-crds
BUILD_CRDS_INTO_DIR ?= $(GEN_CRD_TEMP) # unless overridden, build CRDs into the temp dir
Copy link
Member Author

Choose a reason for hiding this comment

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

So the intermediate steps don't interfere with tracked CSVs.

Comment on lines -92 to +95
@mkdir -p $(CSV_TEMPLATE_DIR)
@cp -a ../../cluster $(CSV_TEMPLATE_DIR)/cluster
@set -eE;\
@ echo yq=$(YQ) operator-sdk=$(OPERATOR_SDK)
mkdir -p $(CSV_TEMPLATE_DIR)
cp -a ../../cluster $(CSV_TEMPLATE_DIR)/cluster
set -eE;\
Copy link
Member Author

Choose a reason for hiding this comment

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

Removing @ symbols here and elsewhere was useful in debugging build issues in the CI for this PR and will be useful in the future as well, so I keep them.

Copy link
Member

Choose a reason for hiding this comment

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

How is it useful in debuging? Is it printing the commands?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, exactly

@BlaineEXE BlaineEXE force-pushed the generate-and-track-csv branch 5 times, most recently from cab8f51 to 6ee770b Compare September 29, 2021 23:16
Start tracking generated CSV templates, and validate that they don't
change in builds.

Signed-off-by: Blaine Gardner <blaine.gardner@redhat.com>
@mergify
Copy link

mergify bot commented Sep 30, 2021

This pull request has merge conflicts that must be resolved before it can be merged. @BlaineEXE please rebase it. https://rook.io/docs/rook/latest/development-flow.html#updating-your-fork

Copy link
Member

@leseb leseb left a comment

Choose a reason for hiding this comment

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

Why do we have to track all the RBACs too? This looks like a lot of duplication from common.yaml, isn't it?

@@ -0,0 +1,151 @@
# OLM: BEGIN OPERATOR DEPLOYMENT
Copy link
Member

Choose a reason for hiding this comment

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

Why is the operator's configmap gone?

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe the OLM generation is broken? I haven't touched any of that code. If it's not here, then I think it hasn't been getting generated for quite some time.

"${YQ_CMD_WRITE[@]}" "$CSV_FILE_NAME" metadata.annotations.externalClusterScript "$(base64 <$CEPH_EXTERNAL_SCRIPT_FILE)"

if [[ "${GENERATE_ROOK_CSV_FOR_TRACKING_ONLY}" != "true" ]]; then
# base64 has different behavior on linux vs macos
Copy link
Member

Choose a reason for hiding this comment

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

what's the difference?

Copy link
Member Author

Choose a reason for hiding this comment

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

MacOS's base64 can only produce a hash on a single line. On Linux, it is multi-line by default.

Comment on lines -92 to +95
@mkdir -p $(CSV_TEMPLATE_DIR)
@cp -a ../../cluster $(CSV_TEMPLATE_DIR)/cluster
@set -eE;\
@ echo yq=$(YQ) operator-sdk=$(OPERATOR_SDK)
mkdir -p $(CSV_TEMPLATE_DIR)
cp -a ../../cluster $(CSV_TEMPLATE_DIR)/cluster
set -eE;\
Copy link
Member

Choose a reason for hiding this comment

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

How is it useful in debuging? Is it printing the commands?

@BlaineEXE
Copy link
Member Author

Why do we have to track all the RBACs too? This looks like a lot of duplication from common.yaml, isn't it?

The RBAC used for CSV is not the same as RBAC from common.yaml. It is a subset. Unless we start providing all the RBAC from common.yaml, I think we should still version them here so we can tell when something specifically related to CSV changes.

@leseb
Copy link
Member

leseb commented Oct 8, 2021

Why do we have to track all the RBACs too? This looks like a lot of duplication from common.yaml, isn't it?

The RBAC used for CSV is not the same as RBAC from common.yaml. It is a subset. Unless we start providing all the RBAC from common.yaml, I think we should still version them here so we can tell when something specifically related to CSV changes.

They should all be the same, if not it could be a bug...

@github-actions
Copy link

github-actions bot commented Nov 7, 2021

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in two weeks if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale Labeled by the stale bot label Nov 7, 2021
@BlaineEXE
Copy link
Member Author

@leseb

I was wanting to revisit this for RBAC generation from the Helm chart (which will/could affect CSV generation). I think it may be best to track the CSV's RBAC for now, then start generating CSV RBAC using a Python script like https://github.com/rook/rook/blob/master/build/rbac/keep-rbac-yaml.py.

If your previous comment (#8862 (comment)) is true, then we should be including all the RBAC in the CSV, and we can stop using # OLM: {BEGIN,END} comments for the generation. This will show us what RBAC is being added compared to the existing set, and we will have a diff to check and see if anything needs to be pruned.

After that, we can decide if we should stop versioning the CSV RBAC or if we should keep it to verify changes to generated RBAC.

Unless you have a better idea for how we can keep track of what changes with generated CSV stuff?

@github-actions github-actions bot removed the stale Labeled by the stale bot label Nov 11, 2021
@leseb
Copy link
Member

leseb commented Nov 26, 2021

@leseb

I was wanting to revisit this for RBAC generation from the Helm chart (which will/could affect CSV generation). I think it may be best to track the CSV's RBAC for now, then start generating CSV RBAC using a Python script like https://github.com/rook/rook/blob/master/build/rbac/keep-rbac-yaml.py.

If your previous comment (#8862 (comment)) is true, then we should be including all the RBAC in the CSV, and we can stop using # OLM: {BEGIN,END} comments for the generation. This will show us what RBAC is being added compared to the existing set, and we will have a diff to check and see if anything needs to be pruned.

After that, we can decide if we should stop versioning the CSV RBAC or if we should keep it to verify changes to generated RBAC.

Unless you have a better idea for how we can keep track of what changes with generated CSV stuff?

No, I think tracking the changes as part of git is good.

@BlaineEXE
Copy link
Member Author

Closing in favor of #9200

@BlaineEXE BlaineEXE closed this Nov 30, 2021
@BlaineEXE BlaineEXE deleted the generate-and-track-csv branch March 1, 2023 22:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants