[CI] skip stages if only docs changes #18315
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
botelastic
bot
added
the
needs_team
💔 Build Failed
Expand to view the summary
Build stats
Test stats 🧪
Log outputExpand to view the last 100 lines of log output
|
This reverts commit 3ab19a3.
v1v
added
ci
Team:Automation
v1v
changed the title
kuisathaverat
approved these changes
May 6, 2020
ycombinator
reviewed
May 6, 2020
Jenkinsfile
Outdated
|
|
||
| // Skip all the stages for PRs with changes in the docs only | ||
| env.ONLY_DOCS = !params.runAllStages && | ||
| isGitRegionMatch(patterns: [ '^docs/.*' ], shouldMatchAll: true) |
There was a problem hiding this comment.
Will this catch changes to files with paths such as ./auditbeat/build/docs/shared/settings60.asciidoc?
There was a problem hiding this comment.
Additionally there are also "source" doc files such as ./filebeat/docs/modules/apache.asciidoc. So I'm wondering if this check needs be more about catching changes to any files (regardless of path) that end in .asciidoc?
There was a problem hiding this comment.
That's indeed a good point, I actually thought it was just this initial PR, and then I found I missed the make update, so working on supporting those particular scenarios too. Thanks for the heads up :) I just moved the PR to draft to work on it.
Regarding the files, I see png files too, I don't know if there are some other type of files. If no, then I can include it in the filter to be file based rather than folder based as you suggested
There was a problem hiding this comment.
Good point re: png files. And, as you said, there might be others too.
How about we start with asciidoc for now, since those do change relatively often, compared to other "non-code" types. And maybe we can add more types later?
There was a problem hiding this comment.
png is also in the list of allowed files, let's then plan the following support files, if any, with some follow-ups. :)
ycombinator
reviewed
May 6, 2020
…alidate changes in the generated files rather than sources
v1v
commented
May 6, 2020
💚 Build Succeeded
Expand to view the summary
Build stats
|
cachedout
approved these changes
May 8, 2020
💔 Build Failed
Expand to view the summary
Build stats
Test stats 🧪
Steps errorsExpand to view the steps failures
Log outputExpand to view the last 100 lines of log output
|
v1v
changed the title
v1v
added a commit
to v1v/beats
that referenced
this pull request
May 8, 2020
v1v
added a commit
to v1v/beats
that referenced
this pull request
May 8, 2020
v1v
added a commit
that referenced
this pull request
May 8, 2020
v1v
added a commit
that referenced
this pull request
May 8, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Skip all the stages, but the checkout and linting, in the pipeline when the changeset is only for changes in any
asciidocandpngfiles independently where they are.NOTE: this particular skip stages feature will only happen for the Pull Requests. In other words, any commits into any branch that are related to those docs files will trigger the builds as expected. This could be changed if required, but let's agree firstly :)
Why is it important?
Fast feedback and avoid unnecessary builds for changes that are purely docs related
How to test this PR locally
It does require a CI to validate his particular behaviour, or tweak the regex to allow changes in the Jenkinsfile and docs. I'll create a commit for testing this particular behaviour.
With a commit that enable the docs only CI
Expand to view
For instance, 7c9e214 caused the build #12
With the above commit and the run all stages
Expand to view
The build #3
Use cases
As a tech writer or docs contributor I do want to get early feedback without the hassle of running through the project build lifecycle.
Tasks