Proposal for Issue Triage/Grooming meeting
by Adam Kaplan
Last week's community call highlighted the need to add an issue
triage/grooming discussion. I'd like to propose we do this every two weeks
at 9:00AM EST, starting this Thursday, March 4th.
If that works I will set up a BlueJeans meeting and send out calendar
invites to folks on the dev mailing list.
--
Adam Kaplan
He/Him
Principal Software Engineer
Red Hat <https://www.redhat.com>
100 E. Davie Street
adam.kaplan(a)redhat.com T: 1-919-754-4843
<https://www.redhat.com>
4 years, 12 months
UPDATE: PRs and the prow 'release-note' plugin
by Gabe Montero
So it's been about a week and from the PR activity I've seen, folks seem to
have adopted the new PR template and release note process just fine.
Of course, folks chime in here if I've missed anything.
That said, I'd like to offer a suggestion:
If folks add kind label(s) to their PR that categories the nature of the
change (feature, bug, api-change, etc.), then the updates to the release
github action I'm working on can look for those labels to facilitate the
sorting of the release notes.
I'll see if there is a way to enforce this use of a kind label on PRs,
though I'm not confident, and if there is not a direct "Fixes ..."
correlation made to a github issue that might be relevant (though event
that could be a stretch), I think we might still have some manual
categorization of release notes required when we cut a new release.
thanks,
gabe
5 years
v0.4.0 Release - date and forward cadence
by Adam Kaplan
Great job everyone getting release v0.3.0 out the door! Since we had
previously discussed more regular releases in the community meetings, I
would like to propose a goal release cadence of every 6 weeks. Under this
schedule our next release date is March 22nd, 2021. I can kick things off
by adding the v0.4.0 milestone in Github.
Please let me know what you think - should we have more frequent releases?
Less frequent? Should we release based on features instead of a "release
train" approach?
Best,
Adam
--
Adam Kaplan
He/Him
Principal Software Engineer
Red Hat <https://www.redhat.com>
100 E. Davie Street
adam.kaplan(a)redhat.com T: 1-919-754-4843
<https://www.redhat.com>
5 years
PRs and the prow 'release-note' plugin
by Gabe Montero
So I've been in the process of proposing use of the Prow release-note plugin
<https://git.k8s.io/community/contributors/guide/release-notes.md>
for easier compilation of release notes for our next dot release.
As part of that, PR https://github.com/shipwright-io/build/pull/585 was
intended to
propose a PR template that would facilitate use of that plugin and start
the discussion.
Now, for the unintended. We needed the OpenShift Test Platform team to
approve
changes to the prow config for our repo before we could tag that change for
merge when we were ready. However, they inadvertently merged that change
instead of only adding the approve label.
So, what to do in the interim:
- I've added the 'release-note-none' and 'release-note' labels needed to
make the plugin happy and not block PR merge. Approvers (i.e. folks in the
OWNERS file) should be able to add the 'release-note-none' label manually
while we sort out https://github.com/shipwright-io/build/pull/585
- Until the PR template is updated, if you'd like to tag your PR for a
release note, you can follow the process described at
https://git.k8s.io/community/contributors/guide/release-notes.md
which will result in the `release-note` label getting added to your PR.
- Or I can pursue reverting the enablement of the plugin, where I again
need approval from the test platform team, and we would then need to repeat
the process if we wanted to use it.
Pending reaching a consensus today via PR/slack/email, I'll add this to the
Monday agenda.
Apologies for the unintended churn in our process as it currently stands.
5 years
Shipwright to be featured at Red Hat Summit!
by Adam Kaplan
Good news - Shipwright will be a featured open source project at Red Hat
Summit this year. We will be sharing a virtual booth with ArgoCD, Eclipse
Che, Helm, Quarkus, and Tekton. In addition, Shoubhik Bose and I will be
running a session dedicated exclusively to Shipwright.
Some of the materials we can create for the booth include:
1. Videos introducing the projects
2. PDFs with guides and datasheets for the project
That said, one of the first things we need to do is submit our logo. Our
new logo is currently being discussed in the linked pull request [1].
Please review and add any final feedback - we need to submit our updated
logo by February 17th, 2021.
[1] https://github.com/shipwright-io/build/issues/325#issuecomment-769920101
--
Adam Kaplan
He/Him
Principal Software Engineer
Red Hat <https://www.redhat.com>
100 E. Davie Street
adam.kaplan(a)redhat.com T: 1-919-754-4843
<https://www.redhat.com>
5 years
Release v0.3.0 is now available
by Enrique Encalada
Hello folks,
We just shipped the v0.3.0 release, see https://github.com/shipwright-io/build/releases/tag/v0.3.0. This release provides mainly enhancements for both Build and BuildRun CRDs.
In general, some of these enhancements are:
- Prevent users from triggering a BuildRun that would eventually fail because of miss-configurations in the Build object. We enhanced the amount of validations we were doing on Build definitions. We also added a watcher on secrets, to allow the Build Registration to be up-to-date depending on the state of it´s referenced secrets.
- Allow users to have a clear understanding of the state of a Build, mainly when a validation failed. We tackle this by redefining the usage of the Build Status fields. It should be very transparent now which validation failed and why.
- Allow users to be able to get more information on the state of a BuildRun, by adopting the "Succeeded" Condition. We also extend the .Status fields, to host the pod/container name of a failed BuildRun. And further customization's on how we populate the "Succeeded" Condition.
- Introduced a new EP around propagating annotations from a BuildStrategy into the pod. This EP also came with the related implementation. This should be useful for admins of strategies.
- A lot of maintenance work, mainly around ensuring our core dependencies (Tekton and Kubernetes) where up-to-date.
- New enhancement on the CI side, the introduction of GitHub Actions is already relieving us from the pain of running all tests in Travis.
Thanks to all that contributed and provided valuable feedback.
Regards,
Enrique E. Encalada
5 years
