Skip to content

Conversation

hebasto
Copy link
Member

@hebasto hebasto commented Dec 18, 2020

This PR:

@hebasto hebasto marked this pull request as draft December 18, 2020 12:24
Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

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

this still "fails" because master doesn't exist when the repo was cloned with go. I think creating the master branch after git fetch will do.

test/lint/commit-script-check.sh $COMMIT_RANGE
else
COMMIT_RANGE="$(git fetch $CIRRUS_REPO_CLONE_URL $CIRRUS_LAST_GREEN_CHANGE && git merge-base $CIRRUS_LAST_GREEN_CHANGE HEAD)..HEAD"
Copy link
Member

Choose a reason for hiding this comment

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

we don't run the linters on any branch because it is too late to fixup any issues that have been merged

Copy link
Member Author

@hebasto hebasto Dec 18, 2020

Choose a reason for hiding this comment

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

Correct. But this is for forked repos and personal Cirrus accounts.

test/lint/lint-git-commit-check.sh and test/lint/lint-whitespace.sh work in all scenarios now.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe submit this as a separate pull? ;)

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks! Done.

test/lint/commit-script-check.sh $COMMIT_RANGE
else
COMMIT_RANGE="$(git fetch $CIRRUS_REPO_CLONE_URL $CIRRUS_LAST_GREEN_CHANGE && git merge-base $CIRRUS_LAST_GREEN_CHANGE HEAD)..HEAD"
Copy link
Member

Choose a reason for hiding this comment

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

Maybe submit this as a separate pull? ;)

@DrahtBot
Copy link
Contributor

DrahtBot commented Dec 19, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

@hebasto
Copy link
Member Author

hebasto commented Dec 20, 2020

Updated 144250e -> 83c07d1 (pr20697.03 -> pr20697.04):

Maybe submit this as a separate pull? ;)

See: #20728.

needs to be guarded by if [ -n "$CIRRUS_PR" ]; then

  • added printing of the COMMIT_RANGE variable value to the log as it was in Travis CI

@hebasto hebasto marked this pull request as ready for review December 20, 2020 12:22
@hebasto hebasto changed the title ci: Fix COMMIT_RANGE variable value ci: Fix COMMIT_RANGE variable value for PRs Dec 20, 2020
Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

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

ACK

# by a pull request this is the name of the branch targeted by the pull request.
# https://cirrus-ci.org/guide/writing-tasks/#environment-variables
COMMIT_RANGE="$CIRRUS_BRANCH..HEAD"
git fetch $CIRRUS_REPO_CLONE_URL $CIRRUS_BASE_SHA
Copy link
Member

Choose a reason for hiding this comment

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

Is this needed?

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually, it replaces the git fetch command from the removed ci/lint/05_before_script.sh

Oh, I see. The CIRRUS_BASE_SHA must already be in the commit history for pulls, right?
I'll push another change without this command.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks! Updated.

@hebasto
Copy link
Member Author

hebasto commented Dec 21, 2020

Updated 83c07d1 -> b4cd93d (pr20697.04 -> pr20697.05, diff):

  • addressed @MarcoFalke's comment

  • fixed COMMIT_RANGE value when a changed PR is force pushed into the base branch that has already grown, i.e., the pull is effectively based on the non-top commit of the base branch

  • added git log command to the lint task log

# by a pull request this is the name of the branch targeted by the pull request.
# https://cirrus-ci.org/guide/writing-tasks/#environment-variables
COMMIT_RANGE="$CIRRUS_BRANCH..HEAD"
COMMIT_RANGE="$(git merge-base $CIRRUS_BASE_SHA $CIRRUS_CHANGE_IN_REPO)..$GIT_HEAD"
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 this changed again? Now it will include master commits, because master has already been merged in for pull requests (see .cirrus.yml)

COMMIT_RANGE="${CIRRUS_BASE_SHA}..$GIT_HEAD" was correct.

Copy link
Member Author

Choose a reason for hiding this comment

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

... master has already been merged in for pull requests (see .cirrus.yml)

Right.

For described case "when a changed PR is force pushed into the base branch that has already grown, i.e., the pull is effectively based on the non-top commit of the base branch" I think COMMIT_RANGE="${CIRRUS_BASE_SHA}..$GIT_HEAD" is wrong, as $CIRRUS_BASE_SHA is not the commit on which the pull is based on.

Copy link
Member

Choose a reason for hiding this comment

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

$CIRRUS_BASE_SHA is not the commit on which the pull is based on.

It is the commit that this pull is de-facto based on, assuming that git merge A is approximately doing the same like git rebase A.

As I mentioned previously the current version is broken and will include all commits that have been pushed to master since. See:

https://cirrus-ci.com/task/5396234322051072?command=lint#L931

Copy link
Member Author

Choose a reason for hiding this comment

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

In .cirrus.yml the base branch is merged into the pull one. That's why I think that listed commits are correct COMMIT_RANGE to lint.

OTOH, we could merge the pull branch into the base one. In that case $CIRRUS_BASE_SHA will work as documented.

Copy link
Member

Choose a reason for hiding this comment

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

That's why I think that listed commits are correct COMMIT_RANGE to lint.

It is not the way it worked on travis

Copy link
Member Author

Choose a reason for hiding this comment

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

Agree.

Is it acceptable to s/git merge A/git rebase A/ ?

Copy link
Member Author

@hebasto hebasto Dec 21, 2020

Choose a reason for hiding this comment

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

I've tested COMMIT_RANGE="${CIRRUS_BASE_SHA}..$GIT_HEAD". It works for all cases.
git is smart enough to know what to do :)

But for a human the value of COMMIT_RANGE is a bit cryptic (regarding to pull commits) in cases of a pull based on the non-top commit of the base branch. So going to skip output of it.

Copy link
Member

Choose a reason for hiding this comment

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

Is it acceptable to s/git merge A/git rebase A/ ?

In theory yes, in practise it doesn't work with subtree bumps.

@maflcko
Copy link
Member

maflcko commented Dec 21, 2020

ACK 3c2478c

maflcko pushed a commit that referenced this pull request Dec 21, 2020
3c2478c ci: Print COMMIT_RANGE to the log as it was in Travis CI (Hennadii Stepanov)
c123892 ci: Drop Travis-specific workaround for shellcheck (Hennadii Stepanov)
10af252 ci: Drop Travis-specific way to set COMMIT_RANGE variable (Hennadii Stepanov)
93504da ci: Fix COMMIT_RANGE variable value for PRs (Hennadii Stepanov)

Pull request description:

  This PR:
  - is a #20658 and #20682  followup
  - set the `COMMIT_RANGE` variable correctly for PRs
  - cleans up Travis-specific code
  - prints COMMIT_RANGE value to the log for convenience as it was in Travis CI

ACKs for top commit:
  MarcoFalke:
    ACK 3c2478c

Tree-SHA512: beb933352b10fd5eb3e66373ddb62439e4f3a03b50fb037ee89fa92c0706cec41d05f2d307f15bb18d1e634e6464f4e123b7e2f88703c8edfd145d8d6eff0b1a
@hebasto
Copy link
Member Author

hebasto commented Dec 21, 2020

Updated b4cd93d -> f89d374 (pr20697.05 -> pr20697.07, diff):

Why is this changed again? Now it will include master commits, because master has already been merged in for pull requests (see .cirrus.yml)

COMMIT_RANGE="${CIRRUS_BASE_SHA}..$GIT_HEAD" was correct.

@maflcko maflcko closed this Dec 21, 2020
@maflcko
Copy link
Member

maflcko commented Dec 21, 2020

This was merged two seconds before you force pushed 😅

@hebasto
Copy link
Member Author

hebasto commented Dec 21, 2020

This was merged two seconds before you force pushed sweat_smile

slow typing :)

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Dec 21, 2020
3c2478c ci: Print COMMIT_RANGE to the log as it was in Travis CI (Hennadii Stepanov)
c123892 ci: Drop Travis-specific workaround for shellcheck (Hennadii Stepanov)
10af252 ci: Drop Travis-specific way to set COMMIT_RANGE variable (Hennadii Stepanov)
93504da ci: Fix COMMIT_RANGE variable value for PRs (Hennadii Stepanov)

Pull request description:

  This PR:
  - is a bitcoin#20658 and bitcoin#20682  followup
  - set the `COMMIT_RANGE` variable correctly for PRs
  - cleans up Travis-specific code
  - prints COMMIT_RANGE value to the log for convenience as it was in Travis CI

ACKs for top commit:
  MarcoFalke:
    ACK 3c2478c

Tree-SHA512: beb933352b10fd5eb3e66373ddb62439e4f3a03b50fb037ee89fa92c0706cec41d05f2d307f15bb18d1e634e6464f4e123b7e2f88703c8edfd145d8d6eff0b1a
@bitcoin bitcoin locked and limited conversation to collaborators Feb 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants