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

Keep kubescape github-action workflow up to date #38

Merged
merged 5 commits into from May 1, 2023
Merged

Keep kubescape github-action workflow up to date #38

merged 5 commits into from May 1, 2023

Conversation

HollowMan6
Copy link
Contributor

@HollowMan6 HollowMan6 commented Apr 9, 2023

I notice that the kubescape version is a bit of old. I have tried to check if we can add an input to allow users to specify the Kubescape image version, but unfortunately this seems like not supported and all the two methods failed:

So I think there will be two way to go:

  • Always use the latest tag.
  • Whenever kubescape upstream makes a new release, bump version tag and make a new release of this github-action with that version tag , so that users can choose the version they want to use. (Maybe this is a better way? I can help automate this process)

HollowMan6 and others added 4 commits April 9, 2023 11:55
Signed-off-by: Hollow Man <hollowman@opensuse.org>
Signed-off-by: Hollow Man <hollowman@opensuse.org>
Signed-off-by: Hollow Man <hollowman@opensuse.org>
@HollowMan6
Copy link
Contributor Author

Just investigated the second way and switched into that. I will add a trigger at the upstream release workflow later: kubescape/kubescape#1186

One of the drawback for this way is that it actually doesn't support publishing to GitHub Marketplace automatically as GitHub forbids us to do so, so we have to edit and update the release manually for each new version to publish the Action to the GitHub Marketplace: cli/cli#5193 (comment)

So I fully understand if you don't like this and we can switch back into the first way instead.

In addition, I removed the build.yaml workflow as it looks like it's no longer needed. I also find that we actually don't need to make sure that workflows have Read and write permissions if we grant the following permissions explicitly in the workflow definition:

actions: read
contents: read
security-events: write

So I add those permissions grant explicitly in the workflow and remove the prerequisites for the ease of users.

@HollowMan6 HollowMan6 requested review from vladklokun and dwertent and removed request for vladklokun April 12, 2023 19:21
Signed-off-by: Hollow Man <hollowman@opensuse.org>
Copy link
Contributor

@dwertent dwertent left a comment

Choose a reason for hiding this comment

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

Nice :)

@dwertent dwertent merged commit 5e49e37 into kubescape:main May 1, 2023
5 checks passed
@HollowMan6
Copy link
Contributor Author

@dwertent

The auto version bumping workflow has failed:

remote: error: GH006: Protected branch update failed for refs/heads/main.        
remote: error: At least 1 approving review is required by reviewers with write access.        
To https://github.com/kubescape/github-action
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/kubescape/github-action'

https://github.com/kubescape/github-action/actions/runs/4853461414/jobs/8649657320

Maybe you want to remove the branch protection for main or make some exceptions to it (although I don't know how to make such exception) to get it fixed.

@HollowMan6
Copy link
Contributor Author

Just opened another PR to change the behavior of this release workflow.

I think you may prefer that way instead of disabling the branch protection for main.

@TRohit20
Copy link

TRohit20 commented Dec 8, 2023

I don't think we need to change the branch protection rules, we can have an action to auto-approve the PR when raised by a specific user. @HollowMan6

@HollowMan6
Copy link
Contributor Author

Just opened another PR to change the behavior of this release workflow.

I think you may prefer that way instead of disabling the branch protection for main.

I don't think we need to change the branch protection rules, we can have an action to auto-approve the PR when raised by a specific user. @HollowMan6

Yeah, go ahead if you want to add the auto-approving

@HollowMan6
Copy link
Contributor Author

We didn't change the the branch protection rules here, it's now using the PR: #56

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

3 participants