Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -2,3 +2,4 @@
node_modules/
.idea
.nyc_output
.tap/
Copy link
Contributor

Choose a reason for hiding this comment

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

Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Shouldn't we keep the tests artifacts from tap out of repository?

Copy link
Contributor

Choose a reason for hiding this comment

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

@Fdawgs

does tap generates artifacts?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here is what I am getting after running npm test

> git status
On branch main
Your branch is behind 'origin/main' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.tap/

no changes added to commit (use "git add" and/or "git commit -a")

image

Copy link
Contributor

Choose a reason for hiding this comment

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

Thats strange, because we have a general .gitignore file and if tap generates artifacts we should also cover them in that file. Thats why I am pinging @Fdawgs

Copy link
Member

@Fdawgs Fdawgs Oct 10, 2023

Choose a reason for hiding this comment

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

@Uzlopak The general .gitignore doesn't have this as I don't believe any other Fastify repo generates tap artefacts.

This repo isn't kept in line with the other ones though as it's a GitHub Action and I don't know what it does/doesn't need 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.

I am happy to remove the .tap/ from the ignore and just not adding the artifacts to the PR. This PR is really just about the doc/readme. And I don't want to introduce additional confusion here.
I guess the topic of what to put in gitignore can be solved elsewhere. WDYT @Uzlopak @Fdawgs ?

Copy link
Member

Choose a reason for hiding this comment

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

Probably best to just add your doc changes, thanks @groozin.

26 changes: 13 additions & 13 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,24 +20,24 @@ Error: Resource not accessible by integration

## Inputs

| input | required | default | description |
| input | required | default | description |
|----------------------------|----------|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `github-token` | No | `${{github.token}}` | A GitHub token. |
| `exclude` | No | | A comma or semicolon separated value of packages that you don't want to auto-merge and would like to manually review to decide whether to upgrade or not. |
| `approve-only` | No | `false` | If `true`, the PR is only approved but not merged. |
| `merge-method` | No | `squash` | The merge method you would like to use (squash, merge, rebase). |
| `merge-comment` | No | `''` | An arbitrary message that you'd like to comment on the PR after it gets auto-merged. This is only useful when you're receiving too much of noise in email and would like to filter mails for PRs that got automatically merged. |
| `use-github-auto-merge` | No | `false` | If `true`, the PR is marked as auto-merge and will be merged by GitHub when status checks are satisfied.<br /><br />_NOTE_: This feature only works when all of the following conditions are met.<br />- The repository enables auto-merge. <br />- The pull request base must have a branch protection rule. <br />- The pull request's status checks are not yet satisfied.<br /></br>Refer to [the official document](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request) about GitHub auto-merge. |
| `target` | No | `any` | A flag to only auto-merge updates based on Semantic Versioning.<br />Possible options are: `major, premajor, minor, preminor, patch, prepatch, prerelease, any`.<br /><br />For more details on how semantic version difference is calculated please see [semver](https://www.npmjs.com/package/semver) package.<br /><br />If you set a value other than `any`, PRs that are not semantic version compliant are skipped. An example of a non-semantic version is a commit hash when using git submodules. |
| `pr-number` | No | | A pull request number, only required if triggered from a workflow_dispatch event. Typically this would be triggered by a script running in a separate CI provider. See [Trigger action from workflow_dispatch event](#trigger-action-from-workflow_dispatch-event) example. |
| `skip-commit-verification` | No | `false` | If `true`, then the action will not expect the commits to have a verification signature. It is required to set this to `true` in GitHub Enterprise Server. |
| `skip-verification` | No | `false` | If true, the action will not validate the user or the commit verification status |
| `github-token` | No | `${{github.token}}` | A GitHub token. |
| `exclude` | No | | A comma or semicolon separated value of packages that you don't want to auto-merge and would like to manually review to decide whether to upgrade or not. |
| `approve-only` | No | `false` | If `true`, the PR is only approved but not merged. |
| `merge-method` | No | `squash` | The merge method you would like to use (squash, merge, rebase). |
| `merge-comment` | No | `''` | An arbitrary message that you'd like to comment on the PR after it gets auto-merged. This is only useful when you're receiving too much of noise in email and would like to filter mails for PRs that got automatically merged. |
| `use-github-auto-merge` | No | `false` | If `true`, the PR is marked as auto-merge and will be merged by GitHub when status checks are satisfied.<br /><br />_NOTE_: This feature only works when all of the following conditions are met.<br />- The repository enables auto-merge. <br />- The pull request base must have a branch protection rule. <br />- The pull request's status checks are not yet satisfied.<br /></br>Refer to [the official document](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request) about GitHub auto-merge. |
| `target` | No | `any` | A flag to only auto-merge updates based on Semantic Versioning.<br />Possible options are: `major, premajor, minor, preminor, patch, prepatch, prerelease, any`.<br /><br />The value of this flag allows for updates for all the matching versions **and lower** with the respect for priority. This means, for example, if the `target` is set to `major` and the update is made to `minor` version the auto-merge will be triggered.<br /><br />For more details on how semantic version difference is calculated please see [semver](https://www.npmjs.com/package/semver) package.<br /><br />If you set a value other than `any`, PRs that are not semantic version compliant are skipped. An example of a non-semantic version is a commit hash when using git submodules. |
| `pr-number` | No | | A pull request number, only required if triggered from a workflow_dispatch event. Typically this would be triggered by a script running in a separate CI provider. See [Trigger action from workflow_dispatch event](#trigger-action-from-workflow_dispatch-event) example. |
| `skip-commit-verification` | No | `false` | If `true`, then the action will not expect the commits to have a verification signature. It is required to set this to `true` in GitHub Enterprise Server. |
| `skip-verification` | No | `false` | If true, the action will not validate the user or the commit verification status |

## Output

| outputs | Description |
| outputs | Description |
|---------------|---------------|
| merge_status | The result status of the merge. It can be one of the following: `approved`, `merged`, `merge_failed`, `skipped:commit_verification_failed`, `skipped:not_a_dependabot_pr`, `skipped:cannot_update_major`, `skipped:bump_higher_than_target`, `skipped:packaged_excluded`|
| merge_status | The result status of the merge. It can be one of the following: `approved`, `merged`, `merge_failed`, `skipped:commit_verification_failed`, `skipped:not_a_dependabot_pr`, `skipped:cannot_update_major`, `skipped:bump_higher_than_target`, `skipped:packaged_excluded` |

## Examples

Expand Down
35 changes: 35 additions & 0 deletions test/action.test.js
Original file line number Diff line number Diff line change
Expand Up @@ -774,3 +774,38 @@ tap.test('should forbid when update type is not valid', async () => {
MERGE_STATUS.skippedInvalidVersion
)
})

tap.test('should allow minor when target is major', async () => {
const PR_NUMBER = Math.random()

const { action, stubs } = buildStubbedAction({
payload: {
pull_request: {
number: PR_NUMBER,
user: { login: BOT_NAME },
},
},
inputs: {
PR_NUMBER,
target: 'major',
},
dependabotMetadata: createDependabotMetadata({
updateType: updateTypes.minor,
}),
})

await action()

sinon.assert.calledWithExactly(
stubs.logStub.logInfo,
'Dependabot merge completed'
)
sinon.assert.notCalled(stubs.coreStub.setFailed)
sinon.assert.calledOnce(stubs.approveStub)
sinon.assert.calledOnce(stubs.mergeStub)
sinon.assert.calledWith(
stubs.coreStub.setOutput,
MERGE_STATUS_KEY,
MERGE_STATUS.merged
)
})