for https://github.com/fleetdm/fleet/issues/15584
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
<!-- Note that API documentation changes are now addressed by the
product design team. -->
- [x] Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#changes-files)
for more information.
- [x] Manual QA for all new/changed functionality
Related to: #10209
Changes:
- Updated the go test in the Makefile to have the `--codepkg` flag.
- Added a newline to the `test-go` GH workflow to trigger a run for this
PR
> Note: I'm creating this as a draft PR to see the results of the "Test
Go" workflow
Update name to "Apply latest configuration profiles and macOS updates"
Because it used to say update MDM (workflow is for more than MDM), and
keeps it in line with workstation group.
Since a lot of bugs end up needing additional product design work, I
propose adding a (commented-out by default) section to this template to
standardize where to add design changes, once settled.
Reasoning: in estimation sessions, it can sometimes be hard to find this
information: sometimes it's in the comments, sometimes it's been added
to the description... either way, its not always obvious to spot. I
think it will help us move quicker if there's a consistent heading to
look for.
(Also, open to suggestions for other ways of wording that heading! This
is just the way I've been adding it to issue descriptions lately.)
These items fix the github action for use with the updates to the
monitoring module.
Additionally there were some changes needed to the monitoring module to
make it behave inside the GH action.
Once this is approved/merged, the new tag for them monitoring module
will be created as `tf-mod-addon-monitoring-v1.1.1`
Clsoes: https://github.com/fleetdm/fleet/issues/14162
Changes:
- Added two steps to the `deploy-fleet-website` workflow to prevent
errors when pushing to the Heroku git repo:
1. The first step runs a command to install the `heroku-repo` plugin in
the Heroku CLI.
2. The second step runs a command to reset the Heroku git repo for the
Fleet website. (This has no impact on the live Heroku app)
- "Head of Product" => "Head of Product Design"
- #help-product => #help-product-design
- "Sprint kickoff review" is now one ritual that includes both MDM and
Endpoint ops teams
- "Pre-sprint prioritization" ritual is now one ritual that includes
both MDM and Endpoint ops teams
- Remove "Sprint release notes kickoff" ritual. Plan is to inform
#g-demand of new features asynchronously. Any discussion that needs to
happen live will happen at product office hours
- Remove "Report number of estimated stories (Endpoint ops))" and
"Report number of estimated stories (MDM)" rituals. One person (Head of
Product Design) is both reporting and tracking product KPIs
- Remove "Bug de-prioritization" ritual. Trying this instead: ~~CEO,~~
Head of Product Design, and Head of Product Development align on next
steps for which bugs to schedule into the next sprint and which can be
de-prioritized during the "Churned bug review" ritual. Less meetings.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
The
[goreleaser-orbit.yaml](https://github.com/fleetdm/fleet/actions/workflows/goreleaser-orbit.yaml)
workflow tends to timeout up to 9-10 times before successfully building
a macOS binary.
We have been using this workflow as a back-up, but it requires doing the
version bump and manually triggering the workflow, which can be error
prone.
This change follows the `workflows/generate-desktop-targets.yml` to
trigger the workflow when the workflow file itself is modified.
Slight shift in the template to focus more on the problems people are
facing. Helps us get to the root of issues without getting sidetracked
by suggested solutions.
---------
Co-authored-by: Mo Zhu <mo@fleetdm.com>
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
Feedback from team that it was not obvious that if you delete it, you
should assume it is free. Probably should not rely on that embedded
assumption going forward, esp. for new engineers.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
I need this change to load test #13926.
Due to recent changes we are not triggering a build on every
branch/commit pushed.
For load testing we need a way to trigger a build manually.