🗞️ About
This morning I had a bunch of news coming to me from GitHub Public Roadmap.
I especially wanted to share two of them as they will have an important impact on our productivity and help us get more insights on our Github Actions.
🔑 Actions: Separate Variables and Secrets
Previously, customers needed to store configuration data as encrypted secrets in order to reuse values in Actions features like reusable workflows. While extremely secure, this method did not allow for easy storage and retrieval of non-sensitive configuration [...]
Actions: Separate Variables and Secrets
#575
Summary
Configuration variables ease the adoption of reusability features in Actions, such as reusable workflows, by providing an easier way to store and share non-sensitive configuration data at either the organization, environment, or repository level.
Intended Outcome
Previously, customers needed to store configuration data as encrypted secrets in order to reuse values in Actions features like reusable workflows. While extremely secure, this method did not allow for easy storage and retrieval of non-sensitive configuration data such as compiler flags, usernames, or server names. An example use case is to set default values for parameters passed to build tools at an organization level, but then allow repository owners to override these parameters on a case-by-case basis.
How will it work?
No response
📊 Actions: Build Performance Insights
Customers need assistance in being able to answer the following questions (among others):
How is my build system performance trending over time,
for individual repositories as well as individual
workflows?
Within a particular workflow, which jobs or steps are
taking the most time? Are these trending better or
worse over time?
How can I correlate changes made to the workflow against performance changes and/or determine if external factors
are the cause of poor performance?
How can I begin to debug poor performance overall,
especially when an individual developer only provides
qualitative inputs ("my build is slow, can you help?")
Actions: Build Performance Insights
#561
Summary
Build performance insights will help customers understand how the build times of their individual workflows, jobs and steps are changing over time, and assist them in troubleshooting poor performance of their CI/CD pipelines.
Intended Outcome
Customers need assistance in being able to answer the following questions (among others):
- How is my build system performance trending over time, for individual repositories as well as individual workflows?
- Within a particular workflow, which jobs or steps are taking the most time? Are these trending better or worse over time? How can I correlate changes made to the workflow against performance changes and/or determine if external factors are the cause of poor performance?
- How can I begin to debug poor performance overall, especially when an individual developer only provides qualitative inputs ("my build is slow, can you help?")
How will it work?
We do not know yet -- that is why this is in the Future column. At the moment we are conducting research on:
- What are the most promising and priority jobs to be done to help customers
- What should be the visual interfaces to see / query / report on this information
- How much should we buy versus build
- Whether customers want to consume this information within our system or if they prefer to send the data elsewhere for their own analysis
and other such questions that will help refine & disambiguate this initiative.
Top comments (2)
@lschaeffer313 : here are some news for ya'