Skip to content
This repository has been archived by the owner on Feb 22, 2023. It is now read-only.

[skip ci] don't run Cirrus on tags #2396

Merged
merged 2 commits into from
Dec 11, 2019
Merged

[skip ci] don't run Cirrus on tags #2396

merged 2 commits into from
Dec 11, 2019

Conversation

fkorotkov
Copy link
Contributor

Description

When all plugins are release at once there will be a tag for each of the plugins but each tag will again test all plugins which makes it not optimal.

Related Issues

Discussion on Discord with @amirh

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
  • All existing and new tests are passing.
  • I updated/added relevant documentation (doc comments with ///).
  • The analyzer (flutter analyze) does not report any problems on my PR.
  • I read and followed the Flutter Style Guide.
  • The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
  • I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
  • I updated CHANGELOG.md to add a description of the change.
  • I signed the CLA.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

  • Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
  • No, this is not a breaking change.

When all plugins are release at once there will be a tag for each of the plugins but each tag will again test all plugins which makes it not optimal.
Copy link
Contributor

@amirh amirh left a comment

Choose a reason for hiding this comment

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

LGTM

I’m still a little worried from the case of non empty pushes with a tag

Cc @cyanglaz we need the same for firebase

Copy link
Contributor

@mklim mklim left a comment

Choose a reason for hiding this comment

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

LGTM

I’m still a little worried from the case of non empty pushes with a tag

I think it depends on how $CIRRUS_TAG is set. Is this set if and only if the current ref is literally a tag, as in it's in .git/refs/tags, or is it set if any tags at all point to the commit hash that this is running on? Assuming it's the former it seems like the right way to go about this. I'm not familiar with how Cirrus handles this, like I mentioned in another channel I'm surprised that it re-runs based on pushes to refs/tags.

@fkorotkov
Copy link
Contributor Author

Cirrus only sets it for refs/tags/* refs. So new pushes to a tag will also have $CIRRUS_TAG set.

"Re-run" on tags is a pretty common workflow in order to do a release. There is usually an extra task to deploy a build somewhere.

@mklim
Copy link
Contributor

mklim commented Dec 11, 2019

Understood, thanks for clarifying @fkorotkov. This is definitely the right fix in our case then.

@mklim mklim merged commit 4652270 into flutter:master Dec 11, 2019
FlutterSu pushed a commit to FlutterSu/flutter-plugins that referenced this pull request Nov 20, 2020
When all plugins are release at once there will be a tag for each of the plugins but each tag will again test all plugins which makes it not optimal.
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.

4 participants