Skip to content
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

Avoid releasing on documentation only changes #1046

Closed
bootstraponline opened this issue Aug 24, 2020 · 5 comments · Fixed by #1053
Closed

Avoid releasing on documentation only changes #1046

bootstraponline opened this issue Aug 24, 2020 · 5 comments · Fixed by #1053
Assignees

Comments

@bootstraponline
Copy link
Contributor

Author the user story for this feature

As a Flank developer, I want to only release snapshots when the code changes so I can save CI compute resources.

Is your feature request related to a problem? Please describe.

Merging a pull request that only ever changes readme.md will produce a new flank snapshot. Let's modify the release pipeline to only perform releases on code changes. As Flank is becoming more of a monorepo, we can add intelligence to CI so that builds only happen when they make sense.

@Sloox
Copy link
Contributor

Sloox commented Aug 25, 2020

After a little bit of research I can see mainly two ways to approach it. But instead of simply just submitting code i would prefer to get some opinions first.

  1. We could introduce a conditional step into the release.yml code and bail out the release process. By leveraging our pull request titles it could be something simple such as:
- name: Check if should release
      run: |
        pattern="(?:\b|')(feat|fix|refactor|perf)(?:\b|')[:]\s"
        title=$(git log --pretty=format:"%s" --abbrev-commit -1)
        if [[ $title =~ $pattern ]]; then 
          echo Not releasing on no code change
          exit 1
        fi;
  1. We could write a custom action that scans through the files and actually checks if the files modified are of extension kt or .doc or anything else and skip the release process.

Is there any other solution that I may have missed?
I am not 100% happy with 1. as there could be mistakes if the title is misnamed.
However number 2 is a larger task and would require some further investigation.

@piotradamczyk5 you are the most familiar with this process. what do you think?

@bootstraponline
Copy link
Contributor Author

bootstraponline commented Aug 25, 2020

If you look at Bitrise (create an account, use selective builds), they have a glob pattern that defines when builds can be triggered. I think we could build something similar using a GitHub action.

For example, only build if changes are in test_runner/**

@piotradamczyk5
Copy link
Contributor

piotradamczyk5 commented Aug 25, 2020

@Sloox you could filter file paths . Please read how to do it in documentation We have some filtering for flank scripts.

Your proposed solution #1 is not good, because it will fail job if nothing changes.
Solution #2 is overkill. Please check Path filter and I am sure that you could handle it.
In case if you have another question please let me know.

Also, I think that we should only filter documentation changes for snapshot. Am I right @bootstraponline ?

@bootstraponline
Copy link
Contributor Author

Also, I think that we should only filter documentation changes for snapshot. Am I right @bootstraponline ?

agreed

@Sloox
Copy link
Contributor

Sloox commented Aug 26, 2020

Thanks will look and get back to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants