This is the situation.
30 minutes ago, I made a release note with tag name v4.2.4
then, just now I make a new release note with tag name 2022-07-18-0013 (this tag name is just about date, my company sometime
use this style version)
As far as I know latest release meaning that the newest release note, But In my case only semantic version(v4.2.4) can have latest tag.
why this is happened?
I can not find any rules about only semantic version has privilege to get a latest.
(I want to know why this is happened, because I use latest release Github API)
------------- EDIT ----------------
git log --oneline print result below
0bc82b8 Merge pull request #166 from devstefancho/feature/0718_test1
2e85d9a add
6cc313e add
4c7e5b2 Merge pull request #165 from devstefancho/feature/0717_test2
f018fca test
b403615 Merge pull request #163 from devstefancho/feature/0717_test2
e7dd66f test
git log --graph --oneline
* 0bc82b8 Merge pull request #166 from devstefancho/feature/0718_test1
|\
| * 2e85d9a add
|/
* 6cc313e add
* 4c7e5b2 Merge pull request #165 from devstefancho/feature/0717_test2
|\
| * f018fca test
* | b403615 Merge pull request #163 from devstefancho/feature/0717_test2
|\|
| * e7dd66f test
|/
------------------- Solved --------------------
Thanks for the great answer, finally figure out!
Reason : same day timestamp
If tags are not created in a same day, then the newest(by time) tag will be latest tag
This information was provided by a GitHub staff member:
Releases are based on Git tags, which mark a specific point in your repository’s history. The sort order of tags is as follows:
Tags are sorted by the timestamp of the underlying commit that they point to
If those commits are created on the same day, then the sorting is based on Semantic Versioning of the name of the tag (https://semver.org/)
If the Semantic Versioning is the same, they are sorted by second of creation
Pre-release versions have a lower precedence than the associated normal version.
Related
I'm exploring how Dependabot works and it isn't working as I expect.
I've created 2 private Golang repos (one, two) with one depending on two:
one's go.mod:
module github.com/dazwilkin/one
go 1.17
require github.com/dazwilkin/two v0.0.0-20210927170438-e7aa41e4107b
NOTE e7aa41e4107b is a prior commit intentionally in order to check VS Code's and Dependabot's update checking.
And dependabot.yml:
version: 2
updates:
- package-ecosystem: "gomod"
directory: "/"
schedule:
interval: "daily"
two's 2 most recent commits are:
curl \
--silent \
--header "Authorization: Bearer ${TOKEN}" \
https://api.github.com/repos/${OWNER}/${REPO}/commits \
| jq -r '.[]|{"sha":.sha,"date":.commit.committer.date}'
And:
{
"sha": "b2f2074829aa61218d7e38f27bb6051ccd97ab7a",
"date": "2021-09-27T18:03:33Z"
}
{
"sha": "e7aa41e4107b8c28f99cadfe55b831380730e808",
"date": "2021-09-27T17:04:38Z"
}
NOTE b2f2074829aa is the commit I'm expecting to be told about and e7aa41e4107b is the prior commit on two that one continues to reference.
VS Code quickly determined that an update is available and:
go list -m -u all
github.com/dazwilkin/one
github.com/dazwilkin/two v0.0.0-20210927170438-e7aa41e4107b [v0.0.0-20210927180333-b2f2074829aa]
NOTE Correctly identifying the latest commit (b2f2074829aa) to replace the prior commit (e7aa41e4107b)
But, after 22 hours and repeated forced updates, dependabot continues to report that e7aa41e4107b is current:
updater | INFO <job_214390230> Starting job processing
updater | INFO <job_214390230> Starting update job for DazWilkin/one
updater | INFO <job_214390230> Checking if github.com/dazwilkin/two 0.0.0-20210927170438-e7aa41e4107b needs updating
updater | INFO <job_214390230> Latest version is 0.0.0-20210927170438-e7aa41e4107b
updater | INFO <job_214390230> No update needed for github.com/dazwilkin/two 0.0.0-20210927170438-e7aa41e4107b
updater | INFO <job_214390230> Finished job processing
NOTE Dependabot appears to have no issue accessing github.com/dazwilkin/two but it doesn't find the most recent commit.
Is this just an eventual consistency issue and I need wait longer?
Update I've waited another 24 hours and it continues to find the earlier commit as the latest version
Or am I misunderstanding or misconfiguring Dependabot?
One perhaps relevant issue that my GitHub account is mixed-case DazWilkin but, for simplicity, I'm publishing and referencing the Golang Modules using all-lowercase (github.com/dazwilkin). However Dependabot appears to have no issues finding the prior commit.
I believe this is because dependabot doesn't support pseudoversions - https://github.com/dependabot/dependabot-core/issues/3017
When I try to tag a specific build through Jenkins, I get the following error:
ERROR: Error tagging repo 'refs/remotes/origin/master' :
org.eclipse.jgit.api.errors.NoHeadException: Tag on repository without
HEAD currently not supported hudson.plugins.git.GitException:
org.eclipse.jgit.api.errors.NoHeadException: Tag on repository without
HEAD currently not supported at
org.jenkinsci.plugins.gitclient.JGitAPIImpl.tag(JGitAPIImpl.java:509)
at
hudson.plugins.git.GitTagAction$TagWorkerThread.perform(GitTagAction.java:199)
at hudson.model.TaskThread.run(TaskThread.java:129) Caused by:
org.eclipse.jgit.api.errors.NoHeadException: Tag on repository without
HEAD currently not supported at
org.eclipse.jgit.api.TagCommand.call(TagCommand.java:137) at
org.jenkinsci.plugins.gitclient.JGitAPIImpl.tag(JGitAPIImpl.java:507)
... 2 more Trying next branch Completed
When trying to tag in the workspace it works fine, HEAD is in fact attached, git refs look fine, could this be an issue that when Jenkins is trying to tag it is looking in the wrong working directory?
Is there a way to pull more verbose logs with how it's trying to tag?
FYI - using the Jenkins 2.81, and swarm Linux agents, latest Git plugin.
Consider the actual code throwing the exception:
try (RevWalk revWalk = new RevWalk(repo)) {
// if no id is set, we should attempt to use HEAD
if (id == null) {
ObjectId objectId = repo.resolve(Constants.HEAD + "^{commit}"); //$NON-NLS-1$
if (objectId == null)
throw new NoHeadException(
JGitText.get().tagOnRepoWithoutHEADCurrentlyNotSupported);
Double-check your configuration: see "Jenkins Git plugin detached HEAD". You need to make sure Jenkins actually does checkout a branch.
Try for instance to add a simple test step with a git status in it, to validate that.
I have setup a job with Jenkins with MultiBranch pipeline.
Github is the SCM and is configured, with a webhook to fire a build on a PR commit. (Existing or new PR).
The build is triggered, all goes fine 1, however the CHANGE_ID is not set (null). We need the CHANGE_ID to pass on to Sonar.
I am struggling to understand, in which cases this parameter is set, and why it's null in our case.
Please consider this question from a Jenkins Multibranch perspective.
Our (git related) plugin installations is here [2] .
1 logging from Jenkins.
[Mon Jun 26 11:32:48 CEST 2017] Received Push event to branch BE-7394 in repository ServiceHouse/api UPDATED event from 172.18.0.1 ⇒ http://jenkins2.servicehouse.nl:8080/github-webhook/ with timestamp Mon Jun 26 11:32:43 CEST 2017
11:32:50 Connecting to https://api.github.com using shojenkinsuser/******
Looking up ServiceHouse/api
11:32:50 Connecting to https://api.github.com using shojenkinsuser/******
Looking up ServiceHouse/api
Getting remote branches...
Checking branch BE-7394
Getting remote branches...
Checking branch BE-7394
‘Jenkinsfile’ found
Met criteria
Changes detected: BE-7394 (01293286b6ee34056d8c92e21a6d39d18e537a81 → 35c16ef01bba5d27dd040a881cd3734fef271fd7)
Scheduled build for branch: BE-7394
0 branches were processed (query completed)
Done examining ServiceHouse/api
[2] Git related Installed plugins:
This variable sutup in the branch-api-plugin (setup source) and we have it working for pull requests or change requests.
For branches of the form -, it is not filled.
I can advise you to use:
BUILD_NUMBER
The current build number, such as "153"
BUILD_ID
The current build ID, identical to BUILD_NUMBER for builds created in
1.597+, but a YYYY-MM-DD_hh-mm-ss timestamp for older builds
I am getting following error in jenkins with github.
Using strategy: Default
Last Built Revision: Revision 8d7d3f0898bc4583a80848033d6e0d27cc3e2096 (origin/master, origin/HEAD)
Fetching changes from 1 remote Git repository
Fetching upstream changes from origin
Seen branch in repository origin/HEAD
Seen branch in repository origin/master
Seen branch in repository origin/svn
Seen 3 remote branches
Commencing build of Revision 8d7d3f0898bc4583a80848033d6e0d27cc3e2096 (origin/master, origin/HEAD)
Checking out Revision 8d7d3f0898bc4583a80848033d6e0d27cc3e2096 (origin/master, origin/HEAD)
FATAL: Invalid id: Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information
java.lang.IllegalArgumentException: Invalid id: Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information
at org.eclipse.jgit.lib.ObjectId.fromString(ObjectId.java:232)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.doRevList(CliGitAPIImpl.java:959)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revList(CliGitAPIImpl.java:945)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.isCommitInRepo(CliGitAPIImpl.java:970)
at hudson.plugins.git.GitAPI.isCommitInRepo(GitAPI.java:181)
at hudson.plugins.git.GitSCM.computeChangeLog(GitSCM.java:1292)
at hudson.plugins.git.GitSCM.access$1300(GitSCM.java:58)
at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1257)
at hudson.plugins.git.GitSCM$4.invoke(GitSCM.java:1211)
at hudson.FilePath.act(FilePath.java:909)
at hudson.FilePath.act(FilePath.java:882)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1211)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1408)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:676)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:581)
at hudson.model.Run.execute(Run.java:1603)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:247)
Normally it works fine during the day and when I start my system again on next day, it gives this error and can only be resolved by re-installing the github in Jenkins. The link in the error message says about Spawning process from build but I don't understand what does that mean (I run 1-2 builds only; on windows).
Thanks.
yesterday I tried to merge a fork and my main branch for a school project. What I usually do is:
Clone my main branch
Merge them
If successful pull the commit of the new branch which was used to merge, if unsuccessful restart
When I did merge the forked branch and the main one, I skipped (or forgot) to merge using a test branch. I guess you figure out what happened, I made mistakes when executing commands and was unsuccessful in my merge, by the time I noticed that, I had already committed.
Now here's a list of what I know:
The clean version of the branch is rev 30
I am unable to clone rev 30 as I receive this: abort: data/inc/presentation/view/PageIndexV.php.i#fc3df292e283: no node!
I have 3 heads for some reason.
I have tried to do hg update -r 30
I tried to revert too
These are my heads
changeset: 35:cf4f3f8519d2
tag: tip
parent: 30:fdb11c78eb12
user: Alexandre * <*#gmail.com>
date: Sat Jun 08 19:07:31 2013 -0400
files: .htaccess
description:
Modif .htaccess
changeset: 34:331201eaa5e2
parent: 30:fdb11c78eb12
user: Alexandre * <*#gmail.com>
date: Sat Jun 08 18:55:19 2013 -0400
files: inc/presentation/view/PageIndexV.php
description:
Test
changeset: 33:6f6f6d4226da
user: Alexandre * <*#gmail.com>
date: Sat Jun 08 18:04:11 2013 -0400
description:
Close branch
Rev 33 was where I tried doing hg commit --close-branch
On Rev 34 I thought maybe adding back the file it's complaining about would help so I added it back (it was not needed anymore so it was deleted)
On rev 35, cpanel had modified .htaccess so I committed it and for some reason it made a new head for no reason...
If any other bit info is needed, just ask, I'll gladly provide it.
I really want to go back or get a copy of revision 30, every bit of info is appreciated, thanks.
Here is what I ended up doing:
I deleted the .hg folder
Did hg init again
then force the pull as they were now unrelated using hg pull -f