Skip to content

Commit

Permalink
Update template and checks
Browse files Browse the repository at this point in the history 
* Update the template to move the tracking issue and the stability level to the front matter
* When a PR is open, check that these fields are valid
* Generate a HTML page for the proposal with these fields.

Signed-off-by: Jeff Mesnil <[email protected]>
  • Loading branch information
@jmesnil
jmesnil committed Jun 27, 2024
1 parent 1b47d85 commit af28396
Show file tree
Hide file tree
Showing 3 changed files with 93 additions and 79 deletions.
33 changes: 33 additions & 0 deletions .scripts/check_proposals
View file
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,21 @@ class MetadataChecker
else
system("gh pr edit #{pr_number} --remove-label invalid-categories")
end
issue_errors = check_issue(pr_number, front_matter)
if issue_errors.length() > 0
errors << issue_errors
system("gh pr edit #{pr_number} --add-label missing-issue")
else
system("gh pr edit #{pr_number} --remove-label missing-issue")
end
stability_level_error = check_stability_level(pr_number, front_matter)
if stability_level_error.length() > 0
errors << stability_level_error
system("gh pr edit #{pr_number} --add-label invalid-stability-level")
else
system("gh pr edit #{pr_number} --remove-label invalid-stability-level")
end

errors
end

Expand All @@ -54,6 +69,24 @@ class MetadataChecker
errors
end

def check_issue pr_number, front_matter
errors = []
unless (front_matter.key? "issue") && (front_matter["issue"] != nil)
errors << "Missing field: issue"
end
errors
end

def check_stability_level pr_number, front_matter
stability_levels = ["experimental", "preview", "community", "default"]

errors = []
unless (front_matter.key? "stability-level") && (stability_levels.include? front_matter["stability-level"])
errors << "Invalid field: stability-level"
end
errors
end

def load_all_categories
yaml = YAML.load_file("_data/wildfly-categories.yaml")
return yaml["categories"]
Expand Down
13 changes: 12 additions & 1 deletion _layouts/proposal.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,17 @@
layout: base
---

{% assign my_variable = false %}


<div class="post-page grid-wrapper">
<div class="grid__item width-10-12">
<h1 class="title">{{page.title}}</h1>
<h1 class="title">
{% if page.stability-level != "default" %}
&lt;{{page.stability-level}}&gt;&nbsp;
{% endif %}
{{page.title}}
</h1>
<div class="grid__item width-10-12 doc-content">

{% unless pages.categories == empty %}
Expand All @@ -14,6 +22,9 @@ <h1 class="title">{{page.title}}</h1>
{% endfor %}
</div>
{% endunless %}
<div style="padding-bottom: 2em;">Tracked by&nbsp;
<a href="{{ page.issue }}">{{ page.issue }}</a>
</div>

{{ content }}
</div>
Expand Down
126 changes: 48 additions & 78 deletions design-doc-template.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,125 +4,95 @@ categories:
# - core
# - management
# if missing, add it to _data/widfly-categories and use its id
#
# Specify the stabitily level of the feature.
# Values can be one of: experimental preview community default
stability-level:
# Specify the main issue of the feature
# Most of the image, it will be a issue in https://issues.redhat.com/browse/WFLY
# or https://issues.redhat.com/browse/WFCORE
issue:
---
= [Experimental|Preview|Community|default]Template <INSERT TITLE HERE>
= <INSERT TITLE HERE>
:author: Your Name
:email: [email protected]
:toc: left
:icons: font
:idprefix:
:idseparator: -

== Overview

== Issue Metadata

=== Issue

* https://issues.redhat.com/browse/WFCORE[WFCORE-XXXX]

=== Related Issues

* https://issues.redhat.com/browse/WFLY[WFLY-XXXX]

=== Stability Level
// Choose the planned stability level for the proposed functionality
* [ ] Experimental
__<The entire document should be one to two pages long. We will write each analysis document as if it is a conversation with a future developer. This requires a good writing style, with full sentences organized into paragraphs. Bullets are acceptable only for visual style, not as an excuse for writing sentence fragments.>__

* [ ] Preview

* [ ] Community

* [ ] default

=== Dev Contacts

* mailto:{email}[{author}]
== Overview

=== QE Contacts
__<Define the requirement here. Be clear and succinct, you should be able to clearly define the context or problem in two or three paragraphs (if not sentences). Try to define the problem in the overall context and not to get into too much technical detail at this point.>__

=== Testing By
// Put an x in the relevant field to indicate if testing will be done by Engineering or QE.
// Discuss with QE during the Kickoff state to decide this
* [ ] Engineering

* [ ] QE
== Affected Projects or Components

=== Affected Projects or Components
__<List the projects or components that are affected by the feature. List them using their Git repositories.>__

=== Other Interested Projects

=== Relevant Installation Types
// Remove the x next to the relevant field if the feature in question is not relevant
// to that kind of WildFly installation
* [x] Traditional standalone server (unzipped or provisioned by Galleon)

* [x] Managed domain

* [x] OpenShift s2i
__<List the installation types thar are relevant for the features and remove any that is not relevant>__.

* [x] Bootable jar
* Traditional standalone server (unzipped or provisioned by Galleon)
* Managed domain
* OpenShift Source-to-Image (S2I)
* Bootable jar

== Requirements

=== Hard Requirements

=== Nice-to-Have Requirements
// Requirements in this section do not have to be met to merge the proposed functionality.
// Note: Nice-to-have requirements that don't end up being implemented as part of
// the work covered by this proposal should be moved to the 'Future Work' section.

__<Describe the requirements that must be fullfilled by this feature.>__

=== Non-Requirements
// Use this section to explicitly discuss things that readers might think are required
// but which are not required.

__<Use this section to explicitly discuss things that readers might think are required but which are not required.>__

=== Future Work
// Use this section to discuss requirements that are not addressed by this proposal
// but which may be addressed in later proposals.

__<Use this section to discuss requirements that are not addressed by this proposal but which may be addressed in later proposals.>__

== Backwards Compatibility

// Does this enhancement affect backwards compatibility with previously released
// versions of WildFly?
// Can the identified incompatibility be avoided?
__<Does this enhancement affect backwards compatibility with previously released versions of WildFly? Can the identified incompatibility be avoided?>__

=== Default Configuration

__<What is the impact of this feature in the default configuration(s) provided by WildFly?>__

=== Importing Existing Configuration

TBD

=== Deployments

__<What is the impact of this feature for deployments?>__

=== Interoperability

//== Implementation Plan
////
Delete if not needed. The intent is if you have a complex feature which can
not be delivered all in one go to suggest the strategy. If your feature falls
into this category, please mention the Release Coordinators on the pull
request so they are aware.
////
__<Is this feature impacting interoperability?>__

== Security Considerations
== Implementation Plan

////
Identification if any security implications that may need to be considered with this feature
or a confirmation that there are no security implications to consider.
////
__<This section is optional. If you have a complex feature which can not be delivered all in one go, suggest the strategy.>__

== Thread Model

__<What impact on security does this feature have?>__

== Test Plan

== Community Documentation
////
Generally a feature should have documentation as part of the PR to wildfly master, or as a follow up PR if the feature is in wildfly-core. In some cases though the documentation belongs more in a component, or does not need any documentation. Indicate which of these will happen.
////
__<How do you plan to test this feature?>__

== Documentation Plan

__<Describe how this feature will be documented or illustrated. Generally a feature should have documentation as part of the PR to wildfly master, or as a follow up PR if the feature is in wildfly-core. In some cases though the feature will bring additional content (such as quickstarts, guides, etc.). Indicate which of these will happen>__

== Release Note Content
////
Draft verbiage for up to a few sentences on the feature for inclusion in the
Release Note blog article for the release that first includes this feature.
Example article: http://wildfly.org/news/2018/08/30/WildFly14-Final-Released/.
This content will be edited, so there is no need to make it perfect or discuss
what release it appears in. "See Overview" is acceptable if the overview is
suitable. For simple features best covered as an item in a bullet-point list
of features containing a few words on each, use "Bullet point: <The few words>"
////

__<Draft verbiage for up to a few sentences on the feature for inclusion in the Release Note blog article for the release that first includes this feature.__
__Example article: http://wildfly.org/news/2018/08/30/WildFly14-Final-Released/.__
__This content will be edited, so there is no need to make it perfect or discuss what release it appears in. For simple features best covered as an item in a bullet-point list of features containing a few words on each, use "Bullet point: <The few words>">__

0 comments on commit af28396

Please sign in to comment.