-
Notifications
You must be signed in to change notification settings - Fork 4
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
Combine TOS acceptance and publication in a single workflow #6
Conversation
aed9c0a
to
661f0d1
Compare
661f0d1
to
0eb3d02
Compare
maven-build-scan/action.yml
Outdated
build-workflow-filename: ${{ inputs.build-workflow-filename }} | ||
pr-comment-tos-acceptance-request: ${{ inputs.pr-comment-tos-acceptance-request }} | ||
- name: Verify Terms of Service acceptance | ||
uses: gradle/github-actions/terms-of-service-acceptance/run@v0.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not super happy with the need for a fully qualified name of the composite action as the tag needs to be updated on each new release (which could easily be forgotten).
The alternative would be to checkout the github-actions
code in the calling workflow to allow calling composite actions with relative paths, this looks worse. though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The common solution to this is to use a version alias (like @v1
) that always points to the latest release. This is done via a tag that is force pushed on each release.
If we do that, then this file won't need to be updated on each release, but it will still contain the fully-qualified path to the action (which I think is OK).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good 👍
@@ -10,39 +10,18 @@ inputs: | |||
required: false | |||
develocity-allow-untrusted: | |||
description: 'Develocity allow-untrusted flag' | |||
default: 'false' | |||
required: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I set the defaults on the top level action only
2c2ebde
to
80b7c5e
Compare
80b7c5e
to
4c3716e
Compare
4c3716e
to
d89c9c8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I can't help but think that this will be a lot simpler if we re-implement in TypeScript. But I like the minimally intrusive requirements on the project.
maven-build-scan/action.yml
Outdated
signature-branch: | ||
description: 'Git branch where the signature file will be stored' | ||
default: ${{ github.event.repository.default_branch }} | ||
signature-location: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably better named "tos-acceptance-file", since it will always be the path to a file, and it records the "tos acceptance".
maven-build-scan/action.yml
Outdated
pr-comment-tos-acceptance-validation: | ||
description: 'pull-request comment added when Terms of Service are accepted' | ||
default: 'All Contributors have accepted Develocity Terms of Service.' | ||
signature-branch: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if "signature" is the best prefix here. This is the branch (and file) where we record TOS-acceptance. Maybe "tos-acceptance-file" and "tos-acceptance-file-branch" would be more self-explanatory as input names.
maven-build-scan/load/action.yml
Outdated
) | ||
&& github.event_name != 'workflow_run' | ||
run: | | ||
echo "Skipping Github event" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This message won't make much sense in the logs on it's own, I don't think. What event is being skipped and why? (Also, maybe this should be logged as DEBUG)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I adjusted the message, I kept it in INFO as I think adding some feedback makes the output clearer
tos-location: 'https://foo.bar/tos.html' | ||
develocity-url: 'https://<MY_DEVELOCITY_URL>' | ||
develocity-access-key: ${{ secrets.<DEVELOCITY_ACCESS_KEY> }} | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
YES! This is all so much simpler from the user point of view, and will make it easier for us to evolve the implementation under the covers.
- name: Publish Build Scan | ||
uses: gradle/github-actions/maven-build-scan@v1.0 | ||
with: | ||
build-workflow-filename: 'build.yml' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unfortunate that this is requires, but I guess that when this workflow is triggered via issue_comment
we have no way of knowing what workflow file might have uploaded build scan artifacts.
with: | ||
pr: ${{ github.event.issue.number }} | ||
workflow_conclusion: success | ||
workflow: ${{ inputs.build-workflow-filename }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I trust that these 3 inputs together mean that we'll only load build scan data that was uploaded by build-workflow_filename
AND it was triggered by a pull_request
event from the specified PR. (We don't want to upload build scans saved by the workflow for a different PR!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this step is called on issue_comment
event only, meaning github.event.issue.number
represents the current PR
Agreed, I'll add the TS based implementation into the backlog |
- rename signature to Terms of Service - Adjust Check event trigger log message - Adjust inner action tags
4e84692
to
3d31e85
Compare
Closing as the following requirement could not be met
|
This PR creates a top-level composite action which aggregates (
load
/verify
/publish
) to offer a single step workflow on consumer side.This modification requires the contributor-assistant to cope with a non
pull_request
event which is addressed by:contributor-assistant/github-action#142