No matter what I do, I cannot seem to get Mylyn to stop inserting a commit message based on a Task even though that task is no longer active and closed. I've tried restarting the app, I've tried activating and inactivating tasks (which seems to simply change the commit message, although this is not consistent).
Switching to different perspectives also does not resolve the problem.
There must be some switch somewhere that I am neglecting to turn off. Please help me fix it!
Summary: Mylyn automatically creates meaningful commit messages based on the tasks you've worked on. To disable them see the Disabling section below.
Disabling: To disable Mylyn's commit messages go to Preferences -> Tasks -> Team and remove all content from the Commit Comment Template.
Details: Mylyn commit messages are automatically generated by using your context to determine which tasks where active when you changed the set of files you are about to commit. Thus, if you had the task implement the submit button active when you changed the file Submit.java then when you commit Submit.java the commit message will automatically be filled in with implement the submit button and a link to that task. Here's an example of a filled in commit message for the task improve upon associations prototype:
Many people find this more convenient than having to copy and paste from your task or type in a commit message yourself. Additionally, there are several advantages to having the commit message filled in by Mylyn, such as having traceability back to the task and having correct annotations. Here's an example of the traceability that having Mylyn-generated commit messages allows. You can see that the code annotations have links directly back to the tasks.
See this article for further details and advantages: Mastering Change-Sets
David Shepherd, Tasktop Technologies http://www.twitter.com/davidcshepherd
Go to Preferences -> Tasks -> Team : clear the Commit Comment Template
Related
I have enabled a couple of different code scanning tools in my GitHub Actions workflow that each upload their results to the GitHub Security tab (via upload-sarif).
One of these scans produces a lot of alerts that are not relevant for my project, as it scans the built container image and produces alerts for all of the packages and utilities included in the base (Linux) image regardless of whether they are used by my application. So I have reviewed all of the alerts on the GitHub Security tab and dismissed (as "Won't Fix") the alerts that are not relevant.
Subsequent executions of the GitHub Actions workflow on the default branch work fine - the code scanning tool still generates all of the alerts, but GitHub sees that the alerts have already been dismissed and doesn't add or re-open them on the Security tab.
However, I also want to run the scan on PRs targeting my default branch in order to catch any new alerts before they are merged. But here GitHub doesn't appear to be checking that the alerts have already been dismissed on the default branch, so the code scanning check fails on every PR. Worse, if I ignore the check and merge the PR anyway, the alerts are transferred over to the default branch and need to be manually dismissed again.
Is there a workaround for this, or should I be approaching this in a different way?
I have discovered that the code scanning tool in question (Trivy) does not include fingerprints in its SARIF output, which is what confuses GitHub. I've made a feature request for Trivy here: https://github.com/aquasecurity/trivy/issues/1840
As a workaround, I've discovered that keeping the container image name static for code scanning allows GitHub's fallback deduplication logic to correctly identify duplicate alerts.
When I go to rebase my development stream with the latest baseline, the current integration stream does not automatically show up. Instead I get a list of all the available streams. When I select the integration stream from the list, I get the following error:
Because this stream has no default stream from which to retrieve
recommended baselines, the baseline list has been seeded with
the stream's current foundation baselines.
To proceed, you'll need to edit the baseline list directly.
(Click 'Advanced' to view/edit the baseline list.)
When I go to Project Explorer, and look at recommended baselines, everything shows up correctly.
This had been working correctly historically. What can I do to set the default stream back to the integration stream?
I didn't saw that error message before, but a workaround would be to:
rename the current child stream (which no longer has the right default parent),
make an new child stream from the integration stream, and rebasing it with the right baseline from its default parent (the integration stream),
make the first child stream (the one with the issue) obsolete,
go on from there.
I can't offer much by way of explanation, but something did magically fix it.
Normally I rebase by right clicking on the development stream and selecting "Rebase Stream...". This was not working. However, Going to Toolbox > UCM > Rebase Stream seemed to kick it into gear.
Not Working
Working
Hopefully that fixes it for some other person. If not, you can go with VonC's answer.
We are working on a single project, and also committing code at the end of day on SVN so that can get all update project. But issues is very often our code getting errors while committing code and projects get empty if someone get update at that time. So my question is are there any set of rules which we've to follow on committing so that every one go on straight path and no one get in trouble and save a lot time from these errors.
Thanks in advance. Cheers
Search Google, something similar to "source control best practices".
Top result has several tips. Sounds like the biggest problem you're facing is integrating with others' changes. Perhaps look into the following sections:
Incorporate others' changes frequently
Share your changes frequently
Coordinate with your co-workers
Investigate why you get errors. Blind application of rules is not good.
For example:
person A committed a code producing compilation error
why?
he finished his task, but hasn't checked build before committing to the trunk
why?
the entire build it too slow
solution: speed-up build, set up continuous build system which will check every commit and notify developers about problems as soon as possible
Another example:
person B committed a code which breaks the build
why?
he wanted to store his changes, but the task is not finished
solution: advice him to create a branch, when the task is finished it can be merged to the trunk (if branch lives for long time, merge changes from trunk to it periodically, then the merge will not be a problem)
There possible other scenarios. With more details you will be able to ask more precise question on StackOverflow and get better answers.
In case of use of SVN co-ordination is must between the team.
Make sure whenever you commit the code you have a idea about what are you committing.
The golden rule is "One developer One class".
If at all two different developers are working on same class. Ask them to maintain a document on what changes they have made. And, most important to mark a comments in a class it self.
There are some important things which need to be followed while committing the code. Whenever you see a conflict in your local files and server files. Make sure you go through every conflict and select the appropriate action.
Understand one important thing, whenever SVN is used one persons mistake can affect everyone.
Whenever possible, don't edit the same line of code as someone else
Leave meaningful comments on your commit messages
Comment your code
Make sure that all the code you commit compiles and runs as it should
Commit when appropriate ie: are passing off part of your code to be used by others or are done working on a feature
Make sure to communicate with other team members
If you find code that you don't know what it does, ask the author
If you're making major changes that will take a while to implement, use a branch and then merge it back in
My team recently switched to all three technologies in the past several months and have worked hard to get it up and running. Next step is automating our changelogs. We have JIRA set up look for the tags (ex. TAG-123) in github commit messages. Jenkins monitors the GitHub commits on a 5 minute timer, pulls, builds, etc.
What I would like to see is a changelog generated automatically when a build is marked as "Promoted to Production." I would like to see it do something akin to the following:
Query Jenkins for the previous build marked as a production release and get the corresponding git commit SHA1.
Run a diff in between the current Git commit and the previous commit
Find all JIRA tickets that are referenced
Compile a list of JIRA titles
Have list export to a text file and placed in build drop (bonus if it can be accessed directly through Jenkins as well)
Whether this flow is followed as written or not is irrelevant--I'm after the end result and am not looking to re-invent the wheel.. Surely somebody done something like this before?
As far as reinvention goes, I was able to find https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin which allows somebody to piggy-back on the Promote to Production action and run a separate script. It would then be a matter of gathering functionality to accomplish the above. (I also noticed Jenkins can tag the current GitHub commit, which my team would likely do in addition.)
Anything closer to accomplishing this would be greatly appreciated.
Thank you!
Since nobody on our team had excess time to devote to this, we ended up throwing together a quick solution.
The Process
Install and setup the All Changes plugin for Jenkins.
When we release, we use "build promotion" system which puts stars next to the previous build, so we can easily see the build# looking at the history.
Copy and paste the relevant output from All Changes into something like notepad++ (human-diff'ing ftw!)
Run a regex find/replace. Search on the regex string, replace with an empty string. (below -- there's the big-bang option or its broken up for understandability.)
Manually organize and release in whatever form is the current agreed up standard.
Everything at once
(\s*\(commit:\s[a-z0-9]{40}.\s..detail)|([\r][\n]#.*\B[\r][\n][\r][\n])|(^[ \t]*)
Remove commit hash\s*\(commit:\s[a-z0-9]{40}.\s..detail
Remove time and surrounding line breaks[\r][\n]#.*\B[\r][\n][\r][\n]
Removing leading whitespace: ^[ \t]*
The Analysis
Pros:
Effective overall
Relatively quick to implement
Cons:
Not fully automated.
Need to revert to commit id if you release from multiple Jenkins jobs.
All Changes history only appears to go back as far as the Jenkins job (I could be mistaken about the specifics of this--I just remember minor grievances with something like this at one point.)
As a whole, the cons are somewhat "the nature of the beast." I'd love to read some other solutions. (For when we have that elusive thing called Time, of course!)
Alternative to dependancy on issue trackers could be to purely use the pull requests themselves. For us they had enough context to generate release notes and we used labels for categorisation. I created PullRequestReleaseNotes and you can try it. It supports GitHub, GitLab, BitBucket and TFS and it can generate release notes in markdown from merged pull requests and its labels and optionally post it to an Atlassian Confluence page and post it to a Slack channel as a post. It can be run as part of continuous integration. Here is a sample:
1.2.1 (MASTER) - XX XXX 2016
Enhancements
Category A
Awesome new feature #1854
Fixes
Category Z
Fixed problem with widget #1792
Category Y
Fixed problem with widget #1792
Fixed exception with view layout #1848
I just want to know if the search result in eclipse search view can be shared with fellow team mate as it is.
I perform a search and delete few unwanted entries and then send it to him/ her
The other person shall be able to view it exactly same manner in the search view.
Is there a way to do this?
The will be very helpful for me
You should be looking at the Mylyn project (http://eclipse.org/mylyn).
This project allows you to create tasks and send them to co-workers through a task repository (such as bugzilla, jira, or most major issue trackers). Attached to these tasks are "contexts", which associate code elements (methods, fields, classes, etc) with the task.
Here is what you would need to do:
Install mylyn (you and all co-workers)
Install the proper connector for your issue tracker (most major issue trackers have one). If you are not using an issue tracker, then you can still import and export tasks as files, but it is less easy to do, and I'd recommend using an issue tracker anyway.
Now add the task repository to your Eclipse. This is the way that mylyn speaks to your issue tracker. It allows you to create issues, bug reports, tasks, etc, from within Eclipse.
With this set up, you can now create a task associated with a task repository and activate it. You can add the desired program elements to your task by right clicking -> Mark as Landmark.
Once you have your task context complete, you can then attach the context to the remote repository (essentially attaching a zip file to the issue in your issue tracker). Other users can then retrieve the context and immediately start working with the context that you created.
It is really a great way to work when you need to share information about specific features in the code to other people on the project.