target / captains-log Goto Github PK
View Code? Open in Web Editor NEWA continuous integration plugin that helps organize release information in slack
Home Page: https://target.github.io/captains-log/
License: Other
A continuous integration plugin that helps organize release information in slack
Home Page: https://target.github.io/captains-log/
License: Other
In our first effort to add more issue trackers, it seems like adding Github issue support would be the next logical step.
When a user links any Github issue or uses any of the close issue syntax helpers, we should be able to show a captains log.
We want to offer out of the box solutions for multiple CI tools. Starting with concourse as it is an easy course of action for us, but we're open to more tools.
There is an issue where, even if you use the correct branch name, CL does not pick up the changes for the changelog.
Notes: It is probably the regex that is the issue.
As a captain's log user, I would like to be able to get notifications to different rooms about my team's release notes, so that I can quickly identify what was released for only my team.
This is also intended to help people send release notes to channels that their team partners can also access, or be aware of.
Example YAML configuration:
teams:
- name: Team Name Here
color: "#8B008B"
emoji: "๐ฑ"
mentions: "<@myTeam>"
channels:
- channel1
- channel2
issueTracking:
jira:
projects:
- FUNKYTOWN
Is your feature request related to a problem? Please describe.
It's common to ask, "What version was this issue or PR fixed in?"
Describe the solution you'd like
Semantic Release does this via the https://github.com/semantic-release/github plug-in
It adds a comment and labels issues and PRs that are included in the release.
Describe alternatives you've considered
n/a
Additional context
Here's what it looks like:
When a slack message is sent, I expect to see a custom heading if I have one.
I only see my custom heading when there are messages in the release log.
Look into the rules for showing the default heading.
N/A
Is your feature request related to a problem? Please describe.
#81 introduces slack blocks to Captain's Log. There is an opportunity to look into a package that manages that for us.
Describe the solution you'd like
https://github.com/raycharius/slack-block-builder
Describe alternatives you've considered
N/A
Additional context
N/A
Captain's Log is showing duplicate tickets when the JIRA ticket is in both the pull request body (description) and the branch name.
Captain's log should uniq
the two arrays to verify that there are not any duplicates.
Captain's log omits the uniq
check on the branch array and the body array combined.
This was a simple oversight in the design. There wasn't an expectation that individuals would be using both features at once.
captains-log/src/utils/ticketFinder/finders/jira/index.js
Lines 16 to 23 in c4e567f
Is your feature request related to a problem? Please describe.
We "hold" Captains Log a bit different than others in that we "release" several times a day. There are many "releases" that are a single Jira ticket.
This results in a lot of screen real estate going to the bug reporting backmatter:
Describe the solution you'd like
A config to disable it, or maybe even make it show up once in every n logs?
Describe alternatives you've considered
Releasing less ๐
Additional context
๐
Jira has a github integration that allows you to link a story to a pull request by using a branch name convention. That looks something like my-branch/JIRA-123
where my-branch
is arbitrary and JIRA-123
is the team and ticket number associated to the pull request.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Today our GitHub regex makes some assumptions about the URL format for GitHub issues that is not consuming from enterprise_host
configuration. This may result in some false positives, such as if I link to an issue on another GitHub instance (such as a reference to a public GitHub issue from an enterprise GitHub PR).
Describe the solution you'd like
A clear and concise description of what you want to happen.
We could update our GitHub URL finder to look for URLs starting with enterprise_host
. That since it is required for non-public GitHub support, so we should be able to count on it. If one is not configured, we can only look for github.com
and www.github.com
URLs.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
What we have today mostly seems to work too, if the complexity here isn't worth it, or there are edge cases we've not considered.
Additional context
Add any other context or screenshots about the feature request here.
n/a
We could support a syntax that would let us refer to issues in PRs, but ignore them for reporting to Captain's Log. Nice if you're working on an issue in multiple phases across multiple releases, and want to refer to it to help PR reviewers, but don't want to misleadingly broadcast it to Slack as completed.
Perhaps:
https://jira.example.com/browse/JIRA-123 <!-- no-captains-log -->
Example:
I am merely referring to this one but it won't be logged due to the comment after it https://jira.example.com/browse/JIRA-123 (view the source).
We could support aliases to the icl
and ecl
ignore comments (#36) that are more obvious - like ignore-captains-log
and end-ignore-captains-log
. Right now people might put icl
/ecl
in their PR templates and then later on others may not know why it's there or for what tool.
Is your feature request related to a problem? Please describe.
Not a problem, but would like if there were more attribution and acknowledgement of the hard work for the people involved in the changes that shipped!
Describe the solution you'd like
It would be cool if the Captain's Log Slack message showed the author of the PR alongside the title, etc.! And maybe even the reviewers/approvers of the PR too. Perhaps only if it can be derived from data we already can pull, and doesn't require additional calls to GitHub that might be too expensive? Maybe still in that case, if we have concerns, we could build it but make it opt-in or opt-out.
Describe alternatives you've considered
n/a
Additional context
n/a
slack workspace tokens are considered secret, so should not be logged in any way.
The error message in the post message handler:
is logging slack url token in CI logs:
Channel not found at URL: xoxp-[REDACTED] TypeError: Only absolute URLs are supported
remove slack token url from log
exposing slack token is a security vulnerability
Looks like the GitHub pull request links in the Slack messages may be pointing to the API URLs, not the HTML URLs. I think the latter would be more useful.
First of all, great work!
Also, nice documentation. however I would like to see the structure/sample files and maybe some example configs.
No Jira stories linked in this release. ๐คทโโ
Think something is broken? Report it here
The empty release message doesn't make sense to users who don't use Jira as their issue tracker.
The empty message should be dynamic based on which ever issue tracker that client has enabled.
The message is hard coded to say Jira.
When using squash merging with Jira Smart Commits, the Jira issue may need to be referenced in the PR title. This way, it will end up in the commit message on the master
branch once merged (since squash merges don't do a rollup of PR commit messages, nor include PR description). Then the Jira GitHub integration can see it and automatically transition the issue. Therefore we could consider looking for Jira issues in the PR title as well as the PR body.
feat: my new feature JIRA-123 #done
@erikkerber found that the new RegExp(tagId, 'g')
has fallen victim to an odd JavaScript "bug".
TL;DR:
The new RegExp
does not need the global
flag, since it is diffing individual strings on a single line, and there will only ever be one match. The current behavior is that it is effectively "caching" the strings that it tests and it misses on "every other" test. A very odd behavior, but a very nice find. We're going to remove this flag in hopes of supporting a more robust tagId
experience.
Stack Overflow Post on what is happening.
Thanks again @erikkerber!
A deployment may require more context than a static message that it has been deployed. A build number, an environment, or even whether the changelog indicates that something has actually been "deployed", depending on a projects workflow.
In increasing complexity:
(I may submit a PR, if I overcome my lifelong avoidance of JS ๐)
If a project is using conventional commits, https://www.conventionalcommits.org/en/v1.0.0-beta.2/, we can leverage that to further filter out information for our users.
The vision here is that "if" a user is using conventional commits, the UI would look the same, but we would add a row that would be emboldened by a title like Features/Bug Fixes/Improvements, etc.
For any commits that didn't follow this, we could just continue to place them directly under the team.
It looks like the formatting for lines that wrap was not handled properly. There should be new lines that make messages or titles line up correctly with their corresponding title or message.
Lines in the slack output are 1:1, meaning that if a title wraps, the message should insert a new line (and vice versa)
Messages are currently not wrapping when titles are wrapping causing the output to look "mashed together".
Is your feature request related to a problem? Please describe.
Users may want to have multiple build steps using different configurations of Captain's Log. This will work if you inline it, but it won't work if you use .captains.yml
.
Describe the solution you'd like
We should find a way where we can support this using .captains.yml
. That would most likely look like convention, or perhaps a k/v association.
Describe alternatives you've considered
N/A
Additional context
N/A
Is your feature request related to a problem? Please describe.
Target's official CI is vela
. Since Captain's Log is part of Target's organization, we should have first class support for Vela.
Describe the solution you'd like
Describe alternatives you've considered
N/A
Additional context
None.
From @AndersDJohnson:
Usually I use either the /abc/gm
literal regex or the new RegExp('abc', 'gm')
constructor but I've not really used the RegExp
constructor with a regex literal as the argument - are we sure this works as expected?
Should we really match any character between <!--
and captains-log-ignore
or only inline whitespace? I guess maybe newlines too? Could try [\n\r\s]+
? Otherwise we might accidentally match a comment like this:
<!-- Here we will use captains-log-ignore to not report to captains-log -->
Are we sure the .
inside [\S\s.]
matches any character and is needed? Try /[.]/.test('a')
- it's false
- it only matches literal .
(/[.]/.test('.')
is true
). But the \S\s
is enough to match any character so I guess it works. ๐คทโโ Alternatively, we may be able to use the /s
modifier (dotAll
) which causes .
to match newlines too - but it's only supported in some JS environments like Node 8.10+ - do we support any lower than that?
We could try this regex?
const STRIP_IGNORE_TICKETS_LONG =
/<!--[\n\r\s]+?captains-log-ignore[\n\r\s]+?-->.*?<!--[\n\r\s]+?end-captains-log-ignore[\n\r\s]+?-->/gms;
I think this is a great idea, and we should update regexs to be more accurate around Captain's Log.
This repository will be archived in 30 days in accordance with Target's internal retention policy.
Archived projects become read-only and will remain accessible to the public.
If you have questions or concerns, reach out here or internally to the OSPO team.
Support the ability to store the teams
object in a file (.captainslog
) in the repo that the CI plugin could consume.
Advantages
.drone.yml
shorter for larger teamsteams
object would not trigger a CODEOWNERS
review for teams who have review restrictions on their pipelines.Is your feature request related to a problem? Please describe.
Commits conforming to the Conventional Commits syntax should be grouped and formatted as they are in the CHANGELOG.md
Describe the solution you'd like
If a commit message uses this syntax, create buckets for at least the type
of commit (feat, fix, etc.) and ignore the tech
and chore
types as is suggested by Standard Version. For all commits that do not conform, but them in an "Other" bucket.
Describe alternatives you've considered
The alternative would be going back to using Slack directly or staying with the current output
Additional context
This is what Standard Version outputs based on conventional commits
Is your feature request related to a problem? Please describe.
Especially with PR templates, many times we just want to omit any ticket link after a certain point. For this reason, a single <!--icl-->
without having to bookend with an <!--ecl-->
would clean up our PR templates by quite a bit.
Describe the solution you'd like
The ignore block would/could match on <!--ecl-->
or the end of the string (PR body)
Describe alternatives you've considered
Perhaps make a whitelist block instead of a blacklist/ignore?
When using multiple issue trackers (e.g. jira and github), sometimes messages are showing up in the default bucket instead of the respective team's.
Team message would go into teams message bucket
Team message is going to default bucket.
Is your feature request related to a problem? Please describe.
We love Captain's Log and would find value in being able to use it to announce release candidates as well as full production release, but we're not sure if it will be easy to tell from the Slack message when it's being posted for a release candidate vs. a full production release.
Describe the solution you'd like
Perhaps we could get an option (or new default) to have the Slack message include the name of the tag being released.
Describe alternatives you've considered
๐คทโโ๏ธ
Additional context
n/a
https://target.github.io/captains-log/#/examples/
The first example here is a bit confusing and could be more clear about enterprise_host
and jira_team_domain
and when to use them.
When comparing commits, tags that are alphabetical are showing up before numerical tags. This causes the comparisons to fail and therefore report nothing.
https://stackoverflow.com/questions/19452244/github-api-v3-order-tags-by-creation-date
This is an existing and intended feature by github when using the v3 API.
The interesting thing here is that it is possible to sort by date using the v4 GraphQL API.
There will need to be some discovery work here on what the right way to proceed is.
@remoz had a cool idea to add a quick link for the slack message formatter directly to console after a successful test.
Example Link:
https://api.slack.com/docs/messages/builder?msg=%7B%22text%22%3A%22I%20am%20a%20test%20message%20http%3A%2F%2Fslack.com%22%2C%22attachments%22%3A%5B%7B%22text%22%3A%22And%20here%E2%80%99s%20an%20attachment!%22%7D%5D%7D
Console logs a message with the correct attachments for that output, like the above link.
For organizations that are releasing from multiple repositories and posting to a single Slack channel, it would be helpful to know which repo triggered the message.
Is there any future plans to add Bit Bucket support?
Currently, we compile lists of links for our Stories column. We recently discovered that there's a limit to the size of this.
The Problem ๐
If you have more than 2,000 chars, Slack cuts off whatever is being listed and moves on. This is obviously an issue, since we want to display all of the information about every story to our users.
Solution? ๐ค
I propose that we handle this by creating a new attachment column with the overflow stories until they're all displayed.
Requirements โ
Must create a new follow up attachment every time the count gets near 2,000 (while avoiding any accidental cutoffs of links)
Must immediately follow the team's attachment
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.