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

use reusable workflows in create-release workflow. #454

Conversation

friedrichwilken
Copy link
Contributor

@friedrichwilken friedrichwilken commented Jan 31, 2024

Description

Changes proposed in this pull request:

  • use reusable workflows for the Create release workflow
  • add unit tests and linting to the Create release workflow
  • automatically bump the sec-scanners-config.yaml

Resons for the removal of some files:

  • scripts/check_release_tag.sh was used in create-release to verify the version the user provided via input. Since we now derive the version from the branch name, this is no longer needed ( it is done here instead).
  • scripts/check_sec-scanners-config.sh was used in the create-release workflow to verify if the release version is the version used in the sec-scanners-config.yaml as the eventing-manager image tag. Since we now render the sec-scanners-config.yaml via bump-sec-scanners-config, this is no longer needed.
  • scripts/create_changelog.sh will be moved to eventing-tools by this PR
  • scripts/create_draft_release.sh will be replaced by create-draft-release-reusable.yml
  • scripts/publish_release.sh will be replaced by publish-release-reusable.yml
  • scripts/render_and_upload_manifests.sh will be replace by render-and-uploader-manifests-reusable.yml
  • scripts/verify-status.sh was used to wait the prow build job to finish successfully. This will happen in trigger-prow-build-job-reusable.yml by using kyma-project/wait-for-commit-status-action.

Related issue(s)
#361

@friedrichwilken friedrichwilken requested review from the1bit and a team as code owners January 31, 2024 13:44
@kyma-bot kyma-bot added area/ci Issues or PRs related to CI related topics cla: yes Indicates the PR's author has signed the CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 31, 2024
@friedrichwilken friedrichwilken added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 31, 2024
@friedrichwilken friedrichwilken linked an issue Jan 31, 2024 that may be closed by this pull request
3 tasks
@kyma-bot kyma-bot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Feb 1, 2024
@friedrichwilken friedrichwilken changed the title add a reusable release workflow use reusable workflows in create-release workflow. Feb 1, 2024
@kyma-bot kyma-bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 1, 2024
@marcobebway marcobebway self-requested a review February 1, 2024 16:40
version: ${{ steps.gen-version.outputs.VERSION }}
gen-version:
name: Generate semantic version from branch and tags
uses: kyma-project/eventing-tools/.github/workflows/get-version-from-release-branch-reusable.yml@main
Copy link
Contributor

@marcobebway marcobebway Feb 1, 2024

Choose a reason for hiding this comment

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

Will this always return the workflow yaml from main~head? If yes, can we use a commit SHA instead, just in case main~head gets broken for some reason.

Note: This also applies to other places in this PR using @main.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, I am happy that you ask about this because I was also between these two options.
Sticking this to a commit sha makes this less susceptible to bug, so yes, let's do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I changed it to a commit sha everywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I need to update the create-draft-release workflow sha, after this PR got merged.

with:
fetch-depth: 0
bump-sec-scanners-config:
name: Bump the sec-scandners-config.yaml
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
name: Bump the sec-scandners-config.yaml
name: Bump the sec-scanners-config.yaml

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed!

bump-sec-scanners-config:
name: Bump the sec-scandners-config.yaml
needs: gen-version
uses: kyma-project/eventing-tools/.github/workflows/bump-sec-scanners-config-reusable.yml@main
Copy link
Contributor

Choose a reason for hiding this comment

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

(nit) ignore for now, after noticing how the reusable workflows are used, maybe it would have been better to use the following naming instead of the current one:

kyma-project/eventing-tools/.github/workflows/reusable/bump-sec-scanners-config.yaml

but this is only my personal preference, so feel free to ignore.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That might have been a helpful solution. You would still find workflows at the expected place and the extra dir would make clear what this is, especially when we are calling them from other workflow like in this case. Learnings for the future.

echo "VERSION=${VERSION}" >> $GITHUB_OUTPUT
run-unit-test:
name: Run Unit Tests
needs: [gen-version, bump-sec-scanners-config]
Copy link
Contributor

Choose a reason for hiding this comment

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

Why does run-unit-test need bump-sec-scanners-config?

Copy link
Contributor Author

@friedrichwilken friedrichwilken Feb 1, 2024

Choose a reason for hiding this comment

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

It does not need it, it will just wait to run the unit tests after bump-sec-scanners-config (because of the PR we create in the that part). In general, all the jobs will run consecutively. Only lint and unit-test will run in parallel because they are independent of each other. That flow is controlled by the need instructions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the only flow that is really needed is the gen-version because only if it get's marked as needs the output (VERSION) gets available in the other jobs.

uses: kyma-project/eventing-tools/.github/workflows/render-and-upload-manifests-reusable.yml@main
with:
VERSION: ${{ needs.gen-version.outputs.VERSION }}
CR_FILE: "somedir/cr_file.yaml"
Copy link
Contributor

Choose a reason for hiding this comment

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

somedir?

Copy link
Contributor Author

@friedrichwilken friedrichwilken Feb 1, 2024

Choose a reason for hiding this comment

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

Oh , I forgot to change the names from tests that I have done earlier. Thanks. I fixed it.

But while I fixed this, I noticed that I have done a mistake when I implemented the flow and only tested it with "somedir/cr_file.yaml".

We need a way to rename the default cr, since gh cannot do it or upload it with a different name.

Here is the fix: would you also take a look at this? I will update the commit sha later, once it was merged.
https://github.com/kyma-project/eventing-tools/pull/66/files

@@ -0,0 +1,57 @@
#!/usr/bin/env bash
Copy link
Contributor

@marcobebway marcobebway Feb 1, 2024

Choose a reason for hiding this comment

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

Does it make sense to move this script to the common tools repo so other repositories may use it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought about this. My intention was to give more flexibility with the changelog (similar to the sec-scanners-config and render-manifest). But you are right, in this case it is not needed at all. I added this PR to do so.

done

# Create a new file (with a unique name based on the process ID of the current shell).
NEW_CONTRIB=$$.new
Copy link
Contributor

Choose a reason for hiding this comment

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

(nit) $$.new -> $$.authors

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

echo -e "\n**Full changelog**: https://github.com/$REPOSITORY/compare/${PREVIOUS_RELEASE}...${RELEASE_TAG}" >>${CHANGELOG_FILE}

# Cleanup the NEW_CONTRIB file.
rm ${NEW_CONTRIB} || echo "cleaned up"
Copy link
Contributor

Choose a reason for hiding this comment

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

(nit) IMO, no need to echo anything here, because removing the file is an internal housekeeping.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I removed the whole section. It is just not needed.

echo "fetching webhook image from ${WEBHOOK_FILE}"
WEBHOOK_IMAGE=$(yq eval '.images[0].newName' <"$WEBHOOK_FILE")
WEBHOOK_TAG=$(yq eval '.images[0].newTag' <"$WEBHOOK_FILE")
echo -e "webhook image is ${WEBHOOK_IMAGE}:${WEBHOOK_TAG} \n"
Copy link
Contributor

@marcobebway marcobebway Feb 1, 2024

Choose a reason for hiding this comment

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

(nit) Maybe set the var WEBHOOK_IMAGE to be ${WEBHOOK_IMAGE}:${WEBHOOK_TAG}.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I like the idea. Done.

Comment on lines 33 to 34
- ${PUBLISHER_IMAGE}
- ${WEBHOOK_IMAGE}:${WEBHOOK_TAG}
Copy link
Contributor

Choose a reason for hiding this comment

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

After applying this comment, these lines should read:

  - ${PUBLISHER_IMAGE}
  - ${WEBHOOK_IMAGE}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated.

@friedrichwilken
Copy link
Contributor Author

I will set this to halt for now. We will first merge this to a test branch, test the release flow and then cherry-pick it to main, once it is ready.

@friedrichwilken friedrichwilken added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 2, 2024
@grischperl grischperl modified the milestone: 1.2.0 Feb 4, 2024
@friedrichwilken friedrichwilken removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 8, 2024
@friedrichwilken friedrichwilken force-pushed the add-reusable-release-workflow branch from 8968d81 to 3720d1f Compare February 8, 2024 09:49
@friedrichwilken friedrichwilken force-pushed the add-reusable-release-workflow branch from e94291a to 0b0d1e1 Compare February 8, 2024 13:28
@kyma-bot
Copy link

kyma-bot commented Feb 8, 2024

@friedrichwilken: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
pull-eventing-manager-build 0b0d1e1 link true /test pull-eventing-manager-build

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ci Issues or PRs related to CI related topics cla: yes Indicates the PR's author has signed the CLA. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants