[HACK] A new CI step to check if dependencies were changed#5420
[HACK] A new CI step to check if dependencies were changed#5420
Conversation
|
You can test the changes on this Pull Request by downloading the APK here. |
AliSoftware
left a comment
There was a problem hiding this comment.
Overall I like the idea. I left a couple of nits/suggestions and questions.
But most importantly, I wonder if this PR shouldn't better wait for the migration of the repo to Buildkite, especially since multiple changes would be needed on those scripts after that migration anyway, and the script code could be simplified on multiple places thanks to Buildkite env vars and commands too…
PS: Do you happen to have a dummy draft PR built on top of this which would add a change in dependency and thus demonstrate the comment that would get posted in such cases? Would be nice to see it in action in a test PR before fully approving anyway 😜
| echo "There are no changes in dependencies of the project" | ||
| rm "$DIFF_DEPENDENCIES_FILE" | ||
| fi | ||
| ./gradlew dependencyTreeDiffCommentToGitHub -DGITHUB_PULLREQUESTID="${CIRCLE_PULL_REQUEST##*/}" -DGITHUB_OAUTH2TOKEN="$GITHUB_API_TOKEN" --info |
There was a problem hiding this comment.
@jkmassel Curious about your thoughts about this:
- This script will require a couple of modifications when we will migrate the repository to Buildkite (hopefully soon), as we'd need to update CircleCI-specific env vars used (like
CIRCLE_PULL_REQUEST,#CIRCLE_PROJECT_USERNAME, etc) - Once we migrate to Buildkite, it might not be worth anymore using yet another way to comment on a PR (i.e. using
gradlehere) compared to using your newcomment_on_prcommand from our buildkite plugin
Though both those changes (updating the env vars used + using comment_on_pr), as well as the simplifications that would be made possible in the script (see below)… would require this PR to wait for the migration to Buildkite to be done before going forward.
Anyway, I'm not sure where you are on your timing of migrating the client app repos to Buildkite… but given we very recently merged the comment_on_pr action which allowed you to start moving forward on this), I figured maybe you planned to start the migration of WCiOS very soon… which means it would be worth waiting for it before landing this PR (with the corresponding changes to make it work in Buildkite)?
There was a problem hiding this comment.
It looks like that @jkmassel is afk. Let's wait then, I think it's not urgent anyway. Ill keep the PR open
| githubResponse="$(curl "$githubUrl" -H "Authorization: token $GITHUB_API_TOKEN")" | ||
| targetBranch=$(echo "$githubResponse" | tr '\r\n' ' ' | ./jq '.base.ref' | tr -d '"') | ||
|
|
||
| mkdir -p $DIFF_DEPENDENCIES_FOLDER |
There was a problem hiding this comment.
Quote the var to avoid issues with spaces in path
In general, I'd suggest you to run shellcheck on your .sh file to get a couple of suggestions to lint this shell script and fix things like this that are otherwise easy to miss 😉
There was a problem hiding this comment.
Interestingly that spellcheck doesn't complain about this line. I quoted anyway though 3f0cc38
| git checkout "$CIRCLE_BRANCH" | ||
| ./gradlew :WooCommerce:dependencies --configuration $CONFIGURATION >$CURRENT_TARGET_BRANCH_DEPENDENCIES_FILE | ||
|
|
||
| ./tools/dependency-tree-diff/dependency-tree-diff.jar $TARGET_BRANCH_DEPENDENCIES_FILE $CURRENT_TARGET_BRANCH_DEPENDENCIES_FILE >$DIFF_DEPENDENCIES_FILE |
There was a problem hiding this comment.
Do we have the source for this JAR? Just so we could understand what it is supposed to do (e.g. what more does it do that a regular diff between the two .txt files wouldn't? Does it mine some Bitcoin behind our backs? What's the license for it?)
There was a problem hiding this comment.
There was a problem hiding this comment.
Nice! Worth a comment above that line in the script to mention that URL for future us IMHO 🙂
| prNumber=$(echo "$CIRCLE_PULL_REQUEST" | sed "s/^.*\/\([0-9]*$\)/\1/") | ||
| githubUrl="https://api.github.com/repos/$CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJECT_REPONAME/pulls/$prNumber" | ||
| githubResponse="$(curl "$githubUrl" -H "Authorization: token $GITHUB_API_TOKEN")" | ||
| targetBranch=$(echo "$githubResponse" | tr '\r\n' ' ' | ./jq '.base.ref' | tr -d '"') |
There was a problem hiding this comment.
Is the tr really necessary here to make jq happy? Shouldn't it be able to parse multiline-JSON files without you needing to remove all CRLFs? 🤔
There was a problem hiding this comment.
JQ was failing to parse the JSON in some cases and I just used this workaround from stackoverflow that fixed the issue. Not sure why it fixes it though
| githubUrl="https://api.github.com/repos/$CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJECT_REPONAME/pulls/$prNumber" | ||
| githubResponse="$(curl "$githubUrl" -H "Authorization: token $GITHUB_API_TOKEN")" | ||
| targetBranch=$(echo "$githubResponse" | tr '\r\n' ' ' | ./jq '.base.ref' | tr -d '"') |
There was a problem hiding this comment.
Note that this whole dance using the GitHub API to retrieve the PR's target branch won't be needed anymore once we migrate to Buildkite, since Buildkite seems to provide the value already via BUILDKITE_PULL_REQUEST_BASE_BRANCH (while the PR's head branch would still be exposed via BUILDKITE_BRANCH similar to the CIRCLE_BRANCH for CircleCI)
One more reason why waiting for the Buildkite migration could help simplify this a lot 🤔
There was a problem hiding this comment.
Yeah, I noticed that other CIs usually do have this build-in. Not Circle CI though.
I think the decision on waiting for the migration on Buildkite or using it already now highly depends on time. I think if we talk about weeks then it's ok to wait. If it's months then maybe we could start using this now and then do the migration. It should not be that complicated
There was a problem hiding this comment.
Agreed. I think the hope 🤞 is to have the CI migration finally done in client repos by the end of year (overflowing on beginning of January 2022 maybe given holiday break?), in any case very soon.
But I'll let @jkmassel chime in here as here's the one tackling this and knowing the timeline estimate and the progress status on this
Co-authored-by: Olivier Halligon <olivier.halligon@automattic.com>
# Conflicts: # WooCommerce/build.gradle
…' into hack/dependency-tree-diff-integr
|
@AliSoftware Thank you for your review! I've just created a dummy PR so the change can be tested in a more comfortable way. //cc @malinajirka |
|
@AliSoftware @kidinov hi folks, thank you for working and reviewing this, I believe it's a great feature! I understand there are concerns about CircleCI -> BuildKite transition but if this PR in current form is not breaking anything, I'd like to suggest if we could merge it? I believe it adds value as it is and if it'll break something - we can quickly disable it and work on it later. My one suggestion to PR itself would be, if it's easy to do, to run this only if PR contains changes in WDYT? |
I agree, but probably it's not my call
Good idea! I can take a look into this improvement later - either as a part of this PR another one |
jkmassel
left a comment
There was a problem hiding this comment.
This looks good to me, and looks nicely portable, so I have no concerns about migration.
I'd love a quick 👍 from @oguzkocer on the gradle task and on the use of a bare .jar file, but that's the only outstanding item.
| CONFIGURATION="vanillaReleaseRuntimeClasspath" | ||
|
|
||
| if [ -n "$CIRCLE_PULL_REQUEST" ]; then | ||
| curl -L "https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64" -o jq |
There was a problem hiding this comment.
In the future, we should be able to assume the host docker image has jq installed instead of installing it using curl.
Nothing to change for this PR, but it'd be a nice simplification / security improvement.
oguzkocer
left a comment
There was a problem hiding this comment.
@jkmassel @kidinov I left a minor suggestion about eager Gradle task generation. This is not a blocker for this PR, but would be good to include it as otherwise I'd need to create a follow up PR for it.
As for the standalone .jar usage - it's outside of the Gradle toolchain, so I have our typical concerns about using including a binary in our repo. Since it's in the CI process, maybe we can consider downloading it from the source instead. Nevertheless, I don't think that should block this PR, we can open a follow-up PR to that if we can agree on an alternative.
Please note that I only reviewed the Gradle changes of this PR. The rest is already reviewed, so I don't think it's necessary for me to review as well.
Co-authored-by: Oguz Kocer <oguzkocer@users.noreply.github.com>
Co-authored-by: Oguz Kocer <oguzkocer@users.noreply.github.com>
…' into hack/dependency-tree-diff-integr
|
Thanks, everyone! I created the issue with improvements - #5639 Merging it for now! |
|
But it did work on #5643 ! |
|
@wzieba I use |
|
You're right, good catch! I had a bad luck (or rather good luck? 😄 ) in choosing PRs. IMO we shouldn't really bother with But I'm wondering about build classpath - I think it'd be nice for cases like #5521 where we learned that updating Edit: but if it'll bump Kotlin stdlib, then it'll become runtime dependency so Edit2: Yeah it showed diff 😄 . So no concerns on my end, thanks again :). |
Description
The PR adds a new CI step that checks if any dependencies (including transitive) were changed and makes a comment on the PR with a list of the dependencies
More details will be published tomorrow in a P2
Testing instructions
RELEASE-NOTES.txtif necessary.