-
Notifications
You must be signed in to change notification settings - Fork 6
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
Show tags next to spec and scenario #42
Comments
Thanks for raising this. I need to investigate what's the best way to pass arguments to the documentation plugin. In |
If it's difficult, then I susgest just showing tags at right side: At the moment, I have to teach which tags are available to filter. And here, how it was implemented: <li><p><b><a href="specs/app/app.html">Home do App</a>
<span style="float: right">[<a href="#">app</a>]</span></b></p>
<ol><li>Exibe informaçoes do integrador<span style="float: right">[<a href="#">app</a>]</span></li><li>Exibe as usinas do usuário<span style="float: right">[<a href="#">app</a>]</span></li><li>Exibe as informações de cada usina<span style="float: right">[<a href="#">app</a>]</span></li><li>Ligar para o telefone do integrador <span style="float: right">[<a href="#">app</a>,<a href="#">manual</a>]</span></li></ol><p></p></li> |
Having a dry run mode is very useful, e.g. in a CI/CD pipeline the dry run mode can be run on feature branches and pull requests to verify that the Gauge specs are in a valid state for publishing. If they are not valid then the CI/CD pipeline build can fail, alerting the submitter of the pull request to amend them on the feature branch. This ensures that the Gauge specs are always in good shape to be automatically published by the CI/CD pipeline upon any push to the trunk branch (e.g. upon a successful pull request merge). The dry run mode is set by setting a `DRY_RUN` environment variable or property (we can't use a command-line flag for this as [Gauge does not propagate command line flags to documentation plugins][1]). [1]: getgauge/spectacle#42 (comment)
Having a dry run mode is very useful, e.g. in a CI/CD pipeline the dry run mode can be run on feature branches and pull requests to verify that the Gauge specs are in a valid state for publishing. If they are not valid then the CI/CD pipeline build can fail, alerting the submitter of the pull request to amend them on the feature branch. This ensures that the Gauge specs are always in good shape to be automatically published by the CI/CD pipeline upon any push to the trunk branch (e.g. upon a successful pull request merge). The dry run mode is set by setting a `DRY_RUN` environment variable or property (we can't use a command-line flag for this as [Gauge does not propagate command line flags to documentation plugins][1]). [1]: getgauge/spectacle#42 (comment)
Having a dry run mode is very useful, e.g. in a CI/CD pipeline the dry run mode can be run on feature branches and pull requests to verify that the Gauge specs are in a valid state for publishing. If they are not valid then the CI/CD pipeline build can fail, alerting the submitter of the pull request to amend them on the feature branch. This ensures that the Gauge specs are always in good shape to be automatically published by the CI/CD pipeline upon any push to the trunk branch (e.g. upon a successful pull request merge). The dry run mode is set by setting a `DRY_RUN` environment variable or property (we can't use a command-line flag for this as [Gauge does not propagate command line flags to documentation plugins][1]). [1]: getgauge/spectacle#42 (comment)
Having a dry run mode is very useful, e.g. in a CI/CD pipeline the dry run mode can be run on feature branches and pull requests to verify that the Gauge specs are in a valid state for publishing. If they are not valid then the CI/CD pipeline build can fail, alerting the submitter of the pull request to amend them on the feature branch. This ensures that the Gauge specs are always in good shape to be automatically published by the CI/CD pipeline upon any push to the trunk branch (e.g. upon a successful pull request merge). The dry run mode is set by setting a `DRY_RUN` environment variable or property (we can't use a command-line flag for this as [Gauge does not propagate command line flags to documentation plugins][1]). [1]: getgauge/spectacle#42 (comment)
Having a dry run mode is very useful, e.g. in a CI/CD pipeline the dry run mode can be run on feature branches and pull requests to verify that the Gauge specs are in a valid state for publishing. If they are not valid then the CI/CD pipeline build can fail, alerting the submitter of the pull request to amend them on the feature branch. This ensures that the Gauge specs are always in good shape to be automatically published by the CI/CD pipeline upon any push to the trunk branch (e.g. upon a successful pull request merge). The dry run mode is set by setting a `DRY_RUN` environment variable or property (we can't use a command-line flag for this as [Gauge does not propagate command line flags to documentation plugins][1]). [1]: getgauge/spectacle#42 (comment)
* Add dry run mode Having a dry run mode is very useful, e.g. in a CI/CD pipeline the dry run mode can be run on feature branches and pull requests to verify that the Gauge specs are in a valid state for publishing. If they are not valid then the CI/CD pipeline build can fail, alerting the submitter of the pull request to amend them on the feature branch. This ensures that the Gauge specs are always in good shape to be automatically published by the CI/CD pipeline upon any push to the trunk branch (e.g. upon a successful pull request merge). The dry run mode is set by setting a `DRY_RUN` environment variable or property (we can't use a command-line flag for this as [Gauge does not propagate command line flags to documentation plugins][1]). [1]: getgauge/spectacle#42 (comment) * Update README with dry run mode info * Bump plugin minor version
Add a
--show-tags
:Then it would generate with tags next to it:
For the software it is important:
But a feature can be verified with a manual testing
I would like a workflow to say witch spec and scenarios would be checked manually, and those status. The ideia is to add tags like
manual, failing or pending
. This way we would mark which spec are tested manually, which was are known as falures (by manual test) and which spec are pending because of steps are developed yet.And I know we can filter it, but this way have separated reports, one for each tag:
The text was updated successfully, but these errors were encountered: